[llvm-commits] [llvm] r43191 - in /llvm/trunk: lib/CodeGen/BranchFolding.cpp test/CFrontend/2007-10-15-VoidPtr.c test/Transforms/BranchFolding/ test/Transforms/BranchFolding/2007-10-19-InlineAsmDirectives.ll

Chris Lattner clattner at apple.com
Mon Oct 22 09:35:47 PDT 2007


On Oct 20, 2007, at 11:49 AM, Dale Johannesen wrote:
> On Oct 20, 2007, at 10:29 AM, Chris Lattner wrote:
>> This is just a really ugly compatibility hack.  Apparently GCC
>> doesn't do cross jumping of inline asm statements as much as we do,
>> and we've hit a significant body of code that depends on this not
>> happening.
>>
>> The code in question is clearly broken, but at this point, I think
>> it's important for LLVM to be "bug compatible" with GCC if it doesn't
>> cost much.  In this case, we only lose tail merging of inline asm
>> statements, which impacts code size but not performance.
>
> Bill's change is not clearly the wrong thing.  People using asm's are
> generally trying to do something they can't do more
> straightforwardly; they know what code they want the compiler to
> produce, and regard writing asm's as an exercise in coercing the
> compiler into producing it.  (They should be writing in assembler
> IMO, but gcc decided years ago to support asm, and we're all stuck
> with it now.)  Before moving to llvm, I was maintaining gcc for some
> time; I never had anybody complain their asm's were not optimized
> enough, and I got many complaints that asm's were optimized too much.

I'm sympathetic to that viewpoint, but it can't be made to work.

In this particular case, the user is using pairs of asms and  
expecting them to come out in the .s file in the same order as they  
wrote.  There is no way the compiler can reasonably guarantee this to  
work: it would prevent all block reordering and control flow  
optimizations etc.  Turning off tail merging happens to fix the cases  
that are failing, but it's just a band-aid, not a solution.

-Chris



More information about the llvm-commits mailing list