On Nov 9, 2017, Jeff Law <l...@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
