Re: Add .def file for public target instructions

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

Richard Sandiford <richard.sandiford@arm.com> writes:
> 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.

...plus (forgot the main reason): the condition for things like return
and simple_return are only available after register allocation.

Thanks,
Richard