llvm dev - Apr 2017 - no-frame-pointer-elim & optimized

Hi,
I have a function with:
  attributes #2 = { "no-frame-pointer-elim"="true" 
"no-frame-pointer-elim-non-leaf" }

Yet when compiling it generates:
https://gist.github.com/carlokok/7c3c98d2fd8c966671f40a5ad94f19d3

(Note how it checks fFinalizer before setting up ebp).
It also has a:
.loc	36 195 7 prologue_end
before this happens

How can I get llvm to do the frame setup before prologue init (so 
debuggers know what is going on)? And if not, how can a debugger know 
where the frame is?

IR:
https://gist.github.com/carlokok/2ba7da8a3f6ed9ae41e0c84d77b528d6

-- 
Carlo Kok
RemObjects Software

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.

-eric

On Tue, Apr 25, 2017 at 10:36 PM Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
> I have a function with:
>   attributes #2 = { "no-frame-pointer-elim"="true"
> "no-frame-pointer-elim-non-leaf" }
>
> Yet when compiling it generates:
> https://gist.github.com/carlokok/7c3c98d2fd8c966671f40a5ad94f19d3
>
> (Note how it checks fFinalizer before setting up ebp).
> It also has a:
> .loc    36 195 7 prologue_end
> before this happens
>
> How can I get llvm to do the frame setup before prologue init (so
> debuggers know what is going on)? And if not, how can a debugger know
> where the frame is?
>
> IR:
> https://gist.github.com/carlokok/2ba7da8a3f6ed9ae41e0c84d77b528d6
>
> --
> Carlo Kok
> RemObjects Software
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170426/8898a8fc/attachment.html>

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.

Unless I'm missing something obvious, this will always screw up debug 
info on Windows 32bits.

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