[llvm-dev] no-frame-pointer-elim & optimized

[Eric Christopher via llvm-dev]

On Wed, Apr 26, 2017 at 12:33 PM David Blaikie <dblaikie at gmail.com> wrote:

> On Wed, Apr 26, 2017 at 11:43 AM Eric Christopher <echristo at gmail.com>
> wrote:
>
>> Adding Quentin here...
>>
>> On Wed, Apr 26, 2017 at 11:31 AM Carlo Kok <ck at remobjects.com> wrote:
>>
>>>
>>>
>>> On 2017-04-26 19:56, Eric Christopher wrote:
>>> > That's really weird. I'm quite surprised that the entry block was moved
>>> > so much later in the function but haven't had a chance to look more at
>>> > it. Probably want to take a look and find out where that's happening
>>> and
>>> > why.
>>>
>>>  From irc, thegameg helped me find the -enable-shrink-wrap=false, which
>>> "fixes" this, although this option doesn't seem to have a switch from
>>> code, only from the llc command line.
>>>
>>>
>> This is a good point. I've not overly thought about how shrink wrapping
>> is going to correlate with entry/exit blocks and prologues. That said, the
>> whole point of shrink wrapping is that the stack adjustments are hidden.
>>
>> I'd have to page in that code to make more than a hand wavy "here's how
>> you'll fix this" though. More thoughts right below though...
>>
>>
>>> Unless I'm missing something obvious, this will always screw up debug
>>> info on Windows 32bits.
>>>
>>>
>> It's pretty much everywhere and just means that the debugger will have
>> some weird state until you actually hit that point. in the code. The
>> problem is that you probably want the debugger to stop at the "beginning"
>> of the function, but with shrink wrapping you won't have stack adjustments
>> at all for that code and if you wait and put the prologue end at the end of
>> the "stack adjustments" then you likely won't stop at all in the function.
>>
>> Tricky.
>>
>> At the moment I'm inclined to believe that this is "correct", but that we
>> really need a better way of distinguishing these entry points.
>>
>> Adrian/Dave: Any other ideas here?
>>
>
> My guess (& this is more a "if someone wants to write patches for this,
> this is the direction I'd suggest" - since it's not a priority for me to do
> this work) would be that once the prologue is sunk beneath instructions
> with other debugloc lines (I think the current theory is that prologue
> locations have no debugloc at all - so basically as soon as you hit any
> debugloc) - it's no longer really the prologue. At that point emit the
> DWARF prologue - describe the value of parameters based on where they are
> at that point (registers, stack offsets, etc) and if you later reach a
> prologue that stuffs the values into stack, etc - emit a new location for
> the variables at that point.
>
>
Agreed. It'll be a bit of work to get right for sure.

-eric


> - Dave
>
>
>>
>> -eric
>>
>>
>>> The check in code to enable this calls:
>>>
>>>
>>>    bool usesWindowsCFI() const {
>>>      return ExceptionsType == ExceptionHandling::WinEH &&
>>>             (WinEHEncodingType != WinEH::EncodingType::Invalid &&
>>>              WinEHEncodingType != WinEH::EncodingType::X86);
>>>    }
>>>
>>> Where EncodingType::X86: //Windows x86, uses no CFI, just EH tables
>>>
>>> The comment seems to imply there are EH tables for i386 Windows, however
>>> I can't find them.
>>>
>>> --
>>> Carlo Kok
>>> RemObjects Software
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170426/fcc3d8dc/attachment.html>