[llvm-commits] [llvm] r106299 - in /llvm/trunk: lib/Target/ARM/ARMISelLowering.cpp test/CodeGen/ARM/call-tc.ll test/CodeGen/ARM/ifcvt6-tc.ll test/CodeGen/ARM/insn-sched1-tc.ll test/CodeGen/ARM/ldm-tc.ll test/CodeGen/Thumb2/thumb2-call-tc.ll test/CodeGen/Thumb2/thumb2-ifcvt1-tc.ll

Evan Cheng evan.cheng at apple.com
Mon Jun 21 11:00:33 PDT 2010


On Jun 21, 2010, at 10:51 AM, Dale Johannesen wrote:

> 
> On Jun 21, 2010, at 10:45 AMPDT, Evan Cheng wrote:
>>>>>> 
>>>>>> On Darwin ARM, this will generate b.w. That's wrong. The .w suffix is for Thumb mode.
>>>>> 
>>>>> Anton was claiming that too, but I don't believe it.  A8.2 says .w "has no effect" when targeting ARM, and the Darwin assembler duly ignores it, correctly IMO.
>>>> 
>>>> Even if the Darwin assembler ignores it, it's still weird. The ".w" suffix only makes sense in Thumb mode, can you fix it?
>>> 
>>> I am not saying this is OK because the Darwin assembler ignores it, I  am saying it is conformant with the spec.  Did you look at A8.2?
>> 
>> I am saying regardless of what the spec allows, it's still inconsistent. llvm only uses .w and .n suffices for Thumb instructions. Consistency is good, no?
> 
> Allowing source that can be assembled in both ARM and Thumb modes is also good.

Huh? The generated assembly function is either in ARM or Thumb mode.

>  So is having less bloat in the compiler.

It's one instruction. Clearly using .w suffix is already generating confusion among engineers. It's the only ARM instruction that uses any size suffix (which makes absolutely no sense since all ARM instructions are 32-bit). Please change it.

Evan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100621/7576c078/attachment.html>


More information about the llvm-commits mailing list