Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

converting 64-bit constant pool entry to 32-bit not necessarily beneficial #1636

Closed
sunfishcode opened this issue Mar 21, 2007 · 5 comments
Closed

converting 64-bit constant pool entry to 32-bit not necessarily beneficial #1636

sunfishcode opened this issue Mar 21, 2007 · 5 comments
Labels
backend:X86 bugzilla Issues migrated from bugzilla code-quality

Comments

@sunfishcode
Copy link
Member

Bugzilla Link 1264
Resolution LATER
Resolved on Mar 05, 2008 11:11
Version trunk
OS All
CC @lattner

Extended Description

For this test case:

define double @​foo(double %x) {
%y = mul double %x, 5.000000e-01
ret double %y
}

llc -march=x86-64 currently produces a 32-bit constant pool entry and this code:

    cvtss2sd .LCPI1_0(%rip), %xmm1
    mulsd %xmm1, %xmm0

instead of just using a 64-bit constant pool entry with this:

    mulsd .LCPI1_0(%rip), %xmm0

This is due to the code in ExpandConstantFP in LegalizeDAG.cpp. It notices that
x86-64 indeed has an instruction to load a 32-bit float from memory and convert
it into a 64-bit float in a register, however it doesn't notice that this isn't
beneficial because it prevents the load from being folded into the multiply.
@lattner
Copy link
Collaborator

lattner commented Mar 21, 2007

Ah, very interesting issue. I see two ways of tackling this:

  1. legalizer could remain unmodified, and we could make the isel pass do something so that it matches
    load+fpextend as a load. When this happened, the isel would have to make a new 64-bit CP entry.

  2. We could disable this legalize xform for x86 and do isel as normal. We could then do the xform as
    an xform after isel (at which point we will know if the load isn't folded). This could be done at sched
    time.

#​1 seems really messy to me. Any other ideas?

-Chris

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 23, 2007

#374 also seems less than ideal to me. It would require yet another specialized
post-isel pass.

I wonder if #​1 can be done with a special isel patten that folds the load (only
from constantpool) and does the transform using a SDNodeXForm. Seems better than
adding the pass if that's possible.

@lattner
Copy link
Collaborator

lattner commented Mar 26, 2007

interesting idea, that might work!

@lattner
Copy link
Collaborator

lattner commented Sep 26, 2007

I moved this to X86/README-SSE.txt

@lattner
Copy link
Collaborator

lattner commented Mar 5, 2008

This is implemented.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
backend:X86 bugzilla Issues migrated from bugzilla code-quality
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@sunfishcode @lattner @llvmbot