Re: Add .def file for public target instructions

[Richard Sandiford <richard.sandiford@arm.com>]

Richard Biener <richard.guenther@gmail.com> writes:
> On Wed, Jul 1, 2015 at 11:39 AM, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
>> On Tue, Jun 23, 2015 at 07:41:42PM +0100, Richard Sandiford wrote:
>>> [A fair bit later than promised, sorry...]
>>>
>>> Mikhail posted a patch to make genflags generate the default HAVE_foo
>>> and gen_foo definitions that have recently been added to defaults.h:
>>>
>>>   https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00723.html
>>>
>>> I agree it'd be a good idea to generate this kind of thing automatically,
>>> but I think we should take the opportunity to move the interface to the
>>> target structure.  I.e.:
>>>
>>>   HAVE_foo -> targetm.have_foo ()
>>>   gen_foo -> targetm.gen_foo ()
>>>
>>> This should move us closer to the pipedream goal of supporting multiple
>>> targets at once.  It should also mean that only the target code depends
>>> on insn-flags.h.
>>
>> using targetm. certainly seems like an improvement.  I wonder if it
>> would be faster to stick this data on a per function object.  I think
>> that would mean you could compute what insns are available once when the
>> function is created and afterwards all checks would only needed to be
>> reading computed values.
>
> I think the memory cost of this is prohibitive.

Yeah.  I did wonder about having optabs-like caching in some
target_globals structure, but I don't think it's really worth it.
In practice we only tend to call the have_*() functions when we're
trying to generate something (unlike optabs), and so any saving would
be dwarfed by the cost of generating whatever rtx we go on to create.

Thanks,
Richard