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

[Jeff Law <law at redhat dot com>]

On 02/10/2018 06:04 AM, Alexandre Oliva wrote:
> On Feb 10, 2018, Jeff Law <law@redhat.com> wrote:
> 
>> So given what I've seen in the ARM port, I don't think we can generally
>> assume any insn advances the PC.
> 
> Ugh.  Thanks, I'll adjust the patch to not count call insns, I guess.
> 
> Maybe what we should have is some target hook that, instead of vowing
> for ATTR_length (or not), tells us whether an insn might not advance the
> PC, with a default that assumes "reasonable" behavior and some more
> conservative alternatives for targets that do messy stuff.  I'll give
> that some more thought.
> 
>> 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.
> 
> Interesting.  I recall some cases back in my SH days in which I needed
> it to be quite precise; I guess this distorted my general expectation.
> Oh well...  Back to the drawing board WRT the locview table
> optimizations.  Maybe we'll find out my concern about them was
> unjustified, and the space they take up is tolerable.  Or maybe we can
> find some way to get the most out of them without actually breaking
> anything.  We'll see...
We have had ports at times try to be very accurate.  You mention the sh,
I also tried for high accuracy on the PA at one time.  I think it was to
support jumps in call delay slots where you have to compute the
difference of two labels.  I eventually gave up and fixed gas :-)  But
the process was still helpful in improving delay slot filling and
instruction scheduling.

jeff