<div dir="ltr"><div>Hello llvm-dev,</div><div><br></div><div>I am trying to fix PR20243.</div><div>The main issue seems to be that the compiler is using a pseudo-instruction to express a TLS global access (in PIC mode on X86 ELF) and that masks the fact that a library call has to be performed. The pseudo-instruction is only lowered in the AsmPrinter, too late for any code that checks whether the function containing the instruction is a leaf function. This affects the decision whether to eliminate the frame pointer in the "eliminate frame pointer only for leaf functions" case.</div><div><br></div><div>I have prepared a patch, and my intention was to mark the TLS access pseudo-instructions with the "isCall" flag, so that they would be recognized as calls.</div><div>However I ran into a problem: the (I believe recently introduced) "FP Stackify" pass tries to interpret the pseudo-instruction as a proper call and it tries to get the return registers, but then it asserts because it gets utterly confused by the pseudo-instruction.</div><div>So, to try to solve this, I had to add the "isPseudo" flag to the instruction, and modify the "FP Stackify" pass to ignore call instructions that are also pseudo (a one-line change).</div><div><br></div><div>This problem suggests to me however that this is probably not the right way to approach the original problem. It's not a good sign if I'm breaking things in the process of fixing other stuff.</div><div><br></div><div>I'm attaching my patch. I would gladly accept any advice on the matter. Am I attacking the issue from the right direction? Is the "isCall" flag the right way to express what the pseudo-instruction does? Or is the usage of a pseudo-instruction itself wrong, and should it be lowered in ISel instead of the AsmPrinter?</div><div><br></div><div>Cheers,</div><div>    Dario Domizioli</div><div>    SN Systems - Sony Computer Entertainment Group</div><div><br></div></div>