[LLVMbugs] [Bug 17280] New: Is there a way to force Using literal pool loads instead of MOVW/MOVT for global/constant value

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=17280

            Bug ID: 17280
           Summary: Is there a way to force Using literal pool loads
                    instead of MOVW/MOVT for global/constant value
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mrcool0905 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 11232
  --> http://llvm.org/bugs/attachment.cgi?id=11232&action=edit
sample code and disassembly dump

We are cross compiling to cortex-m4 cpu from linux with clang 3.3 and we are
really running of Text. Using literal pool loads instead of MOVW/MOVT would
save 2 bytes each time we load a big value, and I am trying to get it working.
Looking at the change from 5101 (ARMv6T2 and later should materialize
GlobalAddresses using MOVW/MOVT), this should be enabled with -Os for global
value, but it doesn't seem working when I compile the code with Os. After
hacking the llvm source code(add a opt to set UseMovt to false), I was able to
get it working on global value, but it still used MOVW/MOVT on constant value.
Seems like constant value code generation follows a different code path which
doesn't check UseMovt. And I noticed that cortex-m0 use literal pool load all
the time since it doesn't have MOVT instruction.

I am wondering if there is a way to force using literal pool loads instead of
MOVW/MOV, or if you can point me to the right place where we generate constant
value instructions, and I can make a patch for myself. 

Attached is the sample code and disassembly dump.

Thanks,
Rui

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130918/05afa316/attachment.html>