On Wed, Aug 19, 2015 at 10:45:42AM +0800, Bin.Cheng wrote: > I ran into back-end address cost issue before and this should be > useful in such cases. Though there are a lot of dumps, it would be > better to classify it into existing dump option (TDF_DETAILS?) and > discard the use of macro.
But TDF_DETAILS is enabled pretty much always, and this costs dump isn't to debug ivopts _itself_. I got the idea from lower-subreg.c, which also uses debug macros like this (and is another place where bad costs tend to show up, btw). > Also the address cost will be tuned/dumped > later, we should differentiate between them by emphasizing this part > of dump is the original cost from back-end. Yeah I should probably print some header, also say e.g. what machine mode some table is for. > > It also shows that the LAST_VIRTUAL_REGISTER trickery ivopts does > > does not work (legitimize_address can create new registers, so now > > a) we have new registers anyway, and b) we use some for multiple > > purposes. Oops). > Yes, that makes seq dump a little weird. It can even make the result wrong -- e.g. (plus (reg 155) (reg 155)) could well be costed differently than (plus (reg 155) (reg 159)). Segher
