[PATCH] Further insn-attrtab.c speedup
Jeff Law
law@redhat.com
Sat Jun 19 02:00:00 GMT 2010
On 06/18/10 15:39, Jakub Jelinek wrote:
> Hi!
>
> This patch implements get_attr_* (insn) caching in insn-attrtab.c.
> insn-attrtab.c contains stuff like:
> case 1685: /* *vec_extractv2di_1_rex64 */
> case 1684: /* *vec_extractv2di_1_rex64_avx */
> extract_constrain_insn_cached (insn);
> if (!((1<< which_alternative)& 0x7))
> {
> return 1;
> }
> else if (get_attr_memory (insn) == MEMORY_BOTH)
> {
> return 3;
> }
> else if (get_attr_memory (insn) == MEMORY_LOAD)
> {
> return 2;
> }
> else if (get_attr_memory (insn) == MEMORY_NONE)
> {
> return 1;
> }
> else
> {
> return 0;
> }
> and get_attr_memory isn't pure (as it can call extract_insn_cached
> or extract_constrain_insn_cached, recog_memoized, etc.).
> This patch instead emits
> enum attr_memory cached_memory ATTRIBUTE_UNUSED;
> ...
> case 1685: /* *vec_extractv2di_1_rex64 */
> case 1684: /* *vec_extractv2di_1_rex64_avx */
> extract_constrain_insn_cached (insn);
> if (!((1<< which_alternative)& 0x7))
> {
> return 1;
> }
> else if ((cached_memory = get_attr_memory (insn)) == MEMORY_BOTH)
> {
> return 3;
> }
> else if (cached_memory == MEMORY_LOAD)
> {
> return 2;
> }
> else if (cached_memory == MEMORY_NONE)
> {
> return 1;
> }
> else
> {
> return 0;
> }
> Similar for conditions like if (something&& (((get_attr_memory (insn) == MEMORY_BOTH) || (get_attr_memory (insn) == MEMORY_LOAD))))
> it emits if (something&& ((((cached_memory = get_attr_memory (insn)) == MEMORY_BOTH || (cached_memory == MEMORY_LOAD))))
> The resulting insn-attrtab.c compiled with -Wuninitialized, so I hope I've done
> all the conditions when the cached attribute can be used finally right.
>
I'd been wondering about this class of insn-attrtab optimizations for a
long time, probably back to the initial days of the SSA work.
Obviously what I was worried about was the potential side effects of the
get_attr_XXX functions since they can execute arbitrary code, which
could include changing the form of the insn (thus changing the return
value of subsequent calls) or something awful like setting global state,
then querying the global state on a subsequent call.
I'm more than happy to consider any such port fundamentally broken. We
should probably document the assumptions we make about the cachability
of the get_attr_XXX calls.
Unfortunately, I'm not qualified to comment on the changes themselves.
I've tried hard through the years to not dive into the genfoo internals.
jeff
More information about the Gcc-patches
mailing list