On Feb 10, 2018, Jeff Law <l...@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... -- 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
