Richard Sandiford <richard.sandif...@arm.com> writes: > Richard Biener <richard.guent...@gmail.com> writes: >> On Wed, Jul 1, 2015 at 11:39 AM, Trevor Saunders >> <tbsau...@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
