On Tue, Sep 29, 2015 at 9:23 PM, Mike Stump <mikest...@comcast.net> wrote:
> On Sep 29, 2015, at 7:31 AM, James Greenhalgh <james.greenha...@arm.com>
> wrote:
>> On Tue, Sep 29, 2015 at 11:16:37AM +0100, Richard Biener wrote:
>>> On Fri, Sep 25, 2015 at 5:04 PM, James Greenhalgh
>>> <james.greenha...@arm.com> wrote:
>>>>
>>>> In relation to the patch I put up for review a few weeks ago to teach
>>>> RTL if-convert to handle multiple sets in a basic block [1], I was
>>>> asking about a sensible cost model to use. There was some consensus at
>>>> Cauldron that what should be done in this situation is to introduce a
>>>> target hook that delegates answering the question to the target.
>>>
>>> Err - the consensus was to _not_ add gazillion of special target hooks
>>> but instead enhance what we have with rtx_cost so that passes can
>>> rely on comparing before and after costs of a sequence of insns.
>>
>> Ah, I was not able to attend Cauldron this year, so I was trying to pick out
>> "consensus" from the video. Rewatching it now, I see a better phrase would
>> be "suggestion with some support”.
>
> I’m not a big fan of rtx_cost. To me it feels more like a crude, sledge
> hammer. Now, that is the gcc way, we have a ton of these things, but would
> be nice to refine the tools so that the big escape hatch isn’t used as often
> and we have more finer grained ways of doing things. rtx_cost should be what
> a code-generator generates with most new ports when they use the nice api to
> do a port. The old sledge hammer wielding ports may well always define
> rtx_cost themselves, but, we should shoot for something better.
>
> As a concrete example, I now have a code-generator for enum reg_class,
> N_REG_CLASSES, REG_CLASS_NAMES, REG_CLASS_CONTENTS, REGISTER_NAMES,
> FIXED_REGISTERS, CALL_USED_REGISTERS, ADDITIONAL_REGISTER_NAMES,
> REG_ALLOC_ORDER and more (some binutils code-gen to do with registers), and
> oh my, it is so much nicer to user than the original api. If you only ever
> have to write once these things, fine, but, if you develop and prototype
> CPUs, the existing interface is, well, less than ideal. I can do things like:
>
> gccrclass
> rc_gprs = “GENERAL”;
>
> r gpr[] = { rc_gprs, Fixed, Used,
> "$zero", "$sp", "$fp", "$lr" };
> r gpr_sav[] = { Notfixed, Notused, alias ("$save_first"),
> "$sav1", "$sav2", "$sav3", "$sav4”,
>
> and get all the other goop I need for free. I’d encourage people to find a
> way to do up an rtx_cost generator. If you're a port maintainer, and want to
> redo your port to use a nicer api to do the registers, let me know. I’d love
> to see progress made to rid gcc of the old crappy apis.
I agree that rtx_cost isn't the nicest thing either. But adding hooks
like my_transform_proftable_p (X *) with 'X' being pass private
data structure isn't very great design either. In fact it's worse IMHO.
Richard.
