This is the mail archive of the
mailing list for the GCC project.
Re: [rfc] multi-word subreg lowering pass
- From: BjÃrn Haase <bjoern dot m dot haase at web dot de>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Richard Henderson <rth at redhat dot com>
- Date: Sat, 7 May 2005 10:48:39 +0200
- Subject: Re: [rfc] multi-word subreg lowering pass
- References: <email@example.com> <20050507033326.GC23300@redhat.com>
Am Samstag, 7. Mai 2005 05:33 schrieb Richard Henderson:
> I hadn't posted this yet because I've yet to show real measurable
> improvements in long long arithmetic on x86. I suspect that I
> won't be able to show this until we have a new register allocator.
> I'd also planned to restructure this so that it uses recog_data to
> replace values in real operands, rather than replacing subregs
> wherever they may be found.
> However, it may be that it's good enough to help the problems that
> AVR is having. If so, I'll go ahead with the rewrite to recog_data.
> The Object is to replace (reg:LARGE X) with a set of (reg:WORD Yi).
> We do this when X is only used in decomposible contexts. Such
> contexts are (1) subregs smaller than or equal to word sized and
> (2) in a decomposible moves.
> If the target leaves logical arithmetic to the middle end, this
> means that the posted example,
> long long foo(int x, long long y)
> return x & y;
> will decompose to
> (set (reg:SI 100) (reg:SI x))
> (set (reg:SI 101) (const_int 0))
> (set (reg:SI 102) (and:SI (reg:SI 100) (reg:SI ylow)))
> (set (reg:SI 103) (and:SI (reg:SI 101) (reg:SI yhigh)))
> (set (reg:SI eax) (reg:SI 102))
> (set (reg:SI edx) (reg:SI 103))
> which after cse and combine will be just perfect.
> Where it fails is when the target has patterns that take multi-word
> inputs. In this case we have to stop and leave the data in the
> multi-word pseudo. This approach does have the advantage of being
> able to work incrementally, though it's also true that incomplete
> conversion can hurt.
Thank you for posting this! ... I will have to study it in more detail, but
IIUC now you have just been implementing the functionality, I have been
desireing quite some time :-) (I used to refer to it as "atomize" pass). I
will go through your patch. I am confident that with it, one could get
significant improvement for the AVR target. This will, however, probably take
a couple of weeks, since IIUC, one would have to implement major
rearrangements in the avr back-end so that after expand we are actually
having RTL that your decomposer pass can work on. With the present monolithic
instructions, I would not expect any improvement.
Best thanks again Yours,