On Oct 22, 2007, at 9:35 AM, Chris Lattner wrote:

> 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.

Yeah, turning all that off is a bit much.  (I did, however, get the  
question
"how do I prevent the compiler from rearranging my code" more than once
from the asm users.  The current answer is "you don't", but this is  
something
that certain people want.)


_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

Reply via email to