Tracking issue for issues marked as pending prototype data

[arunetm]

These issues were marked as pending prototype data. This issue is to track discussions on addressing these before freezing the instruction set.

• Inefficient x64 codegen for float->int truncation: Inefficient x64 codegen for float->int truncation #173
• Concerns about integer vs floating-point instructions on x86: Concerns about integer vs floating-point instructions on x86 #125

[dtig]

I'm inclined to close both of these issues as it's unclear what the next steps are - is there something concrete that you suggest we should do?

For #173, as the float->int trick is sufficient for the application that the issue was filed for, and there were no further responses to that thread, it's unclear what more needs to be done.

For #125 as well, as benchmarks to test integer vs. floating-point instructions haven't come up, and the last request for benchmarks was almost a year ago with no response, it makes sense to me to close as well. More details in the notes for the meeting this was discussed in.

[arunetm]

Sounds good to me. @Maratyszcza, @zeux, is it ok to close these as owners? Do you have any next steps recommendations?

[zeux]

For #173 the only action item would be to open a v8 ticket to investigate alternative codegen sequences. Since it's not clear how we can amend the proposal it's fine to close the issue I think.

[Maratyszcza]

I'm ok with closing #125

[dtig]

For #173 the only action item would be to open a v8 ticket to investigate alternative codegen sequences. Since it's not clear how we can amend the proposal it's fine to close the issue I think.

Would you consider this open issue for loading constants an appropriate follow up? Without this we would need extra instructions to synthesize INT_MAX, and a register move anyway.

[zeux]

@dtig Yeah that works, we can link #173 in that ticket and close, and v8 team can drive the followup work as time permits.

[zeux]

(I should note that I'm hoping to be able to resolve that issue in a max. performant fashion once we get the MVP out and discuss the "fast mode" instructions such as fast recip and float->int; if float->int doesn't have any guarantees about the behavior of out of range/NaN values we can do optimal lowering, and such instruction would be applicable to many use cases - but it's outside of the MVP scope per previous discussion)

[dtig]

Sounds good, thanks.

[dtig]

Closing this issue as the issues this is tracking are closed.