On 02/10/2018 06:04 AM, Alexandre Oliva wrote: > 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... 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
