On Aug 3, 2010, at 4:16 PM, Chris Lattner wrote:
> On Jul 31, 2010, at 5:47 PM, John McCall wrote:
>> On Jul 31, 2010, at 5:38 PM, Chris Lattner wrote:
>>> Inline assembly? Yuck. I thought that [llvm-]gcc just marked tons of
>>> locals as volatile?
>>
>> It does, but then it ends up with all these horrible liveness problems it
>> has to work around.
>> It's also done in a really intrusive way in the type-checker.
>>
>> It looked like my only bet for avoiding that without intrusive changes to IR
>> gen — i.e.
>> some way of saying "okay, these things are volatile even if the AST says
>> they aren't" —
>> was to go back over the function at the end and mark every single load and
>> store
>> as volatile. I didn't really consider that acceptable.
>
> I agree that the gcc implementation of this is terrible, but the end result
> (load/store operations being marked volatile) isn't so terrible. What's
> wrong with a pass after IRGen that marks all accesses to allocas volatile?
Because not all accesses to locals are direct. For example, llvm-gcc gets this
wrong because p's type after annotation is 'int * volatile', not 'int volatile
* volatile':
void opaque();
int main(int argc, char **argv) {
int x = 0, *p = &x;
@try {
*p = 5;
opaque();
} @catch (id) {
return 1;
}
}
And of course you can do things like this:
void add_two(int *x) { (*x) += 2; }
...
int x = 0;
@ try {
add_two(&x);
opaque();
}
which then breaks under inlining, etc. Even with inline assembly I'm not quite
able to avoid all of this, even with a further fix I'm still testing, but I can
get a lot closer than llvm-gcc can.
All the evil here springs from lowering to setjmp in the frontend. setjmp was
not designed to be injected into unsuspecting code like this; doing so is
orders of magnitude worse than my empty assembly constraints. I am basically
playing a game of chicken with the backend, particular since apparently nobody
quite wants to admit that setjmp is a special case that they have to treat
differently when, say, calculating liveness.
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
