This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] ivopts costs debug
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 19 Aug 2015 03:55:16 -0500
- Subject: Re: [PATCH] ivopts costs debug
- Authentication-results: sourceware.org; auth=none
- References: <9f6de433cd9a44841992b7ac3eebc6106e3c3e7e dot 1439931648 dot git dot segher at kernel dot crashing dot org> <CAHFci29LOKXN2POqkNgm5G6R-YmV9DHHZn0PyjU46mBBEFtMWQ at mail dot gmail dot com>
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