Re: [PATCH 9/9] [IEPM] Introduce inline entry point markers

[Alexandre Oliva <aoliva@redhat.com>]

On Nov  9, 2017, Jeff Law <law@redhat.com> wrote:

>> I didn't want yet another rtl code that would have to be added to
>> cases all over; the distinction between markers matters at only very
>> few points in the compiler.

> Is it fair to say one is just a variant of the other?

I don't see them that way, but the fact that there's a name that applies
to a whole class of potential debug markers, two of which are
implemented in this patchset, could imply they are.  They're variants of
debug markers, and as such optimization passes should generally leave
them alone.  They are all supposed to carry information about relevant
points in the source program throughout compilation, but they differ in
what the points are.

They currently don't carry any information besides their lexical block
and source location information, which makes a single RTL code enough,
but this could change: stmt markers could link back to a representation
of the source statement, if we had one; inline entry point markers could
link back to the original call that was inlined; end-of-prologue markers
might require other kinds of data I can't think of; return value
assignment points and actual return points also come to mind.  These are
the markers I've thought of so far; many of them are no more than ideas
yet to be implemented.

> Is there a bit we could use in the rtx flags?

As long as we have only two kinds of markers, yes.  Even more than that,
probably.

Now, I've just looked at the actual data, and my concern that having
separate RTL codes would require them to appear in tons of locations is
unfounded.  The only occurrence of DEBUG_MARKER, aside from that in
macros defined in rtl.h, is in extract_insn.c.

OTOH, having multiple RTL codes to check for in e.g. DEBUG_MARKER_INSN_P
(or DEBUG_BIND_INSN_P) could have a larger impact on the compiler
performance than I would like; these macros are used very often, and
currently they have to test three RTL codes: DEBUG_INSN, and then either
VAR_LOCATION or DEBUG_MARKER.  As long as one of the classes has only
one RTL code, we can test by negating the other (like
DEBUG_MARKER_INSN_P currently tests that the pattern is *not*
VAR_LOCATION), but if both classes were to have more than one RTL code,
the tests would become more expensive.  So I strive to reduce the number
of codes tested for in such pervasive tests, and, should that become
unavoidable, to keep them in sequence, so that the compiler can optimize
a sequence of tests to a range test, or maybe use distinct RTX_CLASSes
for them.

>> Changing that would make for a very localized patch, touching only this
>> creation point, the macro that tells the kinds apart, and the
>> documentation, so if you'd rather have something else, I'll be glad to
>> comply.
> Alternately, let's at least abstract things via a macro or getter/setter
> type function so that we can change the implementation in the future
> without having to do searches on mode twiddling.

Done in a patch I'm about to push to the branch.  (I was just about to
post the updated patchset when I got your email; now it will be a bit
later ;-)

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer