This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: set_src_cost lying comment
- From: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, "law at redhat dot com" <law at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 24 Jun 2015 16:08:41 +0000
- Subject: RE: set_src_cost lying comment
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=pass (sender IP is 149.199.60.83) smtp.mailfrom=xilinx.com; gcc.gnu.org; dkim=none (message not signed) header.d=none;
- References: <20150622055710 dot GQ1723 at bubble dot grove dot modra dot org> <558A3AA9 dot 6090406 at redhat dot com> <20150624091846 dot GC1723 at bubble dot grove dot modra dot org> <558ACA63 dot 20608 at redhat dot com> <20150624155752 dot 69D6F33CA8 at vlsi1 dot gnat dot com>
-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of Richard Kenner
Sent: Wednesday, June 24, 2015 9:28 PM
To: law@redhat.com
Cc: gcc@gcc.gnu.org
Subject: Re: set_src_cost lying comment
> These are good examples of things the costing model simply wasn't ever
> designed to consider -- because they weren't significant issues on
> the m68k, vax and other ports in the gcc-1 era.
>
> So I don't really know how to tell you to proceed -- I've considered
> the costing models fundamentally flawed for many years, but haven't
> ever tried to come up with something that works better.
>>I'm not sure I'd call it "fundamentally flawed" or that it wasn't "designed to consider" these things. I see the costing model as meant as a *heuristic* for >>making choices, not as a precise metric for anything. Certainly, a lot of people worked on that model, including both of us, during the gcc-2 RISC porting days.
>>I see the "flaw" as trying to use it for too much. There's a limit to the amount of decisions you can make with purely local data. When trying to decide >>whether a source should be a constant or a register, you have to look at:
>>- the chances the reg-reg copy can be eliminated
>>- register pressure
>>- whether there's room to insn schedule around any conflicts
Increasing or decreasing the cost of moves affects the Optimal Coalescing. Also the Live range splitting that generates the shuffle code
at the border if the registers in the partner live ranges are different/ Splitted live ranges where a partner has register and another partner
in memory, then a store would be needed otherwise a load is generated with respect to the live range has memory and the partner live
ranges in register then a load will be generated. All these conditions and heuristics are associated with move cost for x86 and other Architecture.
Thanks & Regards
Ajit
>>Unless you look at the whole picture, you're just guessing, which is, of course, what a heuristic is all about!