Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Jeff Law <law at redhat dot com>]

On 02/09/2018 09:39 PM, Alexandre Oliva wrote:
> On Feb  9, 2018, Alexandre Oliva <aoliva@redhat.com> wrote:
> 
>> On Feb  9, 2018, Jeff Law <law@redhat.com> wrote:
>>> On 02/08/2018 08:53 PM, Alan Modra wrote:
>>>> On Fri, Feb 09, 2018 at 01:21:27AM -0200, Alexandre Oliva wrote:
>>>>> Here's what I checked in, right after the LVU patch.
>>>>>
>>>>> [IEPM] Introduce inline entry point markers
>>>>
>>>> One of these two patches breaks ppc64le bootstrap with the assembler
>>>> complaining "Error: view number mismatch" when compiling
>>>> libdecnumber.
>>>>
>>> I've just passed along a similar failure (.i, .s and command line
>>> options) to Alex for ppc64 (be) building glibc.
> 
>> Thanks.  So, I'm told there are more such issues, that non-asm insn
>> length attrs can't be relied on at this time to be nonzero only when the
>> actual length is not zero.
> 
> I wonder...  In the previously-posted patch, we still regard call insns
> are advancing PC.  I think that's a safe assumption, but...  are there
> any other kinds of patterns we could recognize that would certainly
> generate an actual PC-changing insn?  How about jump insns?  How about
> insns that are SETs, or PARALLELs containing at least one SET?  Does
> anyone see any risk in recognizing those when the length attr is,
> conservatively or not, deemed unreliable?  Any other paterns we could
> recognize to that end?
So given what I've seen in the ARM port, I don't think we can generally
assume any insn advances the PC.

Here's why.

On the ARM there's a little state machine that's used to implement
conditional execution.   When we're in certain states the backend will
generate no code for certain JUMP_INSNs and change the state.

That's fine and dandy.  THe problem is we can't actually tell outside
the ARM backend when that's happened!

You might think we could embed tests of the FSM within the length
computation.  But the state of the FSM is only valid during assembly
output (e.g. final).  But insn lengths are set up during branch
shortening and if you query the length attribute you get value computed
by branch shortening.

The only way around this would be to do what I would consider some
interface abuse and query insn_min_length (not to be confused with
get_attr_min_length).  Then we wouldn't get the cached version and we
could do queries of the state machine on the fly in
dwarf2out_var_location.  But it seems rather icky and I haven't even
been able to convince myself it's really safe.

And while this is specific to the ARM and JUMP_INSNs, I can easily
envision scenarios where other ports could use the same kind of little
state machine for standard INSNs (PA to generate add,tr) or even
CALL_INSNs (target dependent optimization of tail calls).

You also have to worry about ports that try to optimize away nop-insns
that snuck through the optimizers.   I once worked on a port that
couldn't encode a register self copy.  So when one snuck through the
optimizers, we had to deal with it in the output code and I know I've
seen other instances where ports tried to compensate for nop-insns that
snuck through.

So in the end I don't think you can assume that any given insn advances
the PC.  The closest we have is the length attribute, but it has always
supposed to have been conservatively correct for the purposes of branch
shortening.  ie, it can never return a length less than the actual
length, but it is allowed to return a length longer than the actual length.

Jeff