Hello, David>> Don't do that (tm) > > Why not?They will be eliminated w/o any visible effect.>> I'm testing the fix. > > Ok, I'll try to "mark noredzone" thing and see if that works.It does, I verified this with the testcase you attached to PR. The problem is not stack allocation, but red zone thing. As I already said, I'm testing the fix; since it touches some target independent code as well, I need to be sure that I haven't screwed stuff on other targets. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Wednesday 09 December 2009 13:42, Anton Korobeynikov wrote:> Hello, David > > >> Don't do that (tm) > > > > Why not? > > They will be eliminated w/o any visible effect.Hmm...As I said I added them in our 2.5 implementation and they didn't get eliminated. The stack gets properly adjusted and everyone's happy. Our 2.5 implementation creates the call to __tls_get_addr manually in the X86ISelLowering code. In TOT special SDNodes are generated which get matched by TableGen patterns and dump out a fixed sequence of instructions which includes the call. I'm guessing that's the critical difference. Is there a reason that route was taken in TOT? Why have an SDNode represent a bunch of instructions rather than just "properly" creating them?> >> I'm testing the fix. > > > > Ok, I'll try to "mark noredzone" thing and see if that works. > > It does, I verified this with the testcase you attached to PR. The > problem is not stack allocation, but red zone thing.Well, we shouldn't be using the redzone because any function that uses TLS is not a leaf (at least on X86). Simply marking the function "noredzone" seems like a bit of a hack to me. How do we guarantee some other piece of code that thinks the function is a leaf won't do something else to screw things up? -Dave
> Is there a reason that route was taken in TOT? Why have an SDNode represent > a bunch of instructions rather than just "properly" creating them?Yes. We need to be sure that "special" code is glued properly to the call (mostly due to presence of post-RA scheduler). And technically this "bunch of instructions" is a whole, not something + call.> Well, we shouldn't be using the redzone because any function that uses > TLS is not a leaf (at least on X86). Simply marking the function "noredzone" > seems like a bit of a hack to me. How do we guarantee some other piece of > code that thinks the function is a leaf won't do something else to screw > things up?As I said, this is temporary workaround until I will commit a fix (just in the case if you're in hurry). -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University