This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] multi-word subreg lowering pass

> From: Björn Haase <>
>> Am Sonntag, 8. Mai 2005 09:48 schrieb Paul Schlie:
>>> From: Richard Henderson <>
>>> ...
>>> The Object is to present the register allocator with something that
>>> it has more freedom to work with.  This doesn't achieve that goal.
>> Thanks, after building HEAD with your patches applied, I think I better
>> understand.  However there seem to be a few odd things going on. Which the
>> following code attempts to show: (including signed char casts for lowered
>> operands even though compiled with unsigned chars, and oddly better code
>> for in-lined calls than for identical expressions, and finally if the below
>> function zed is defined first, the compile will terminate with a bus
>> error):
> ... I think that it is not very useful to test Richard's patch with the
> present back-end.

- actually it seems to work fairly well; and thought it would be ok given
that the expressions are "lowered" prior to code generation (therefore
although wider mode operations remain specified, the lowered one's would be
selected automatically if operations/operands are "pre-lowered", which seems
to be the case, but maybe I'm entirely missing something)?

> I think also that at this stage we should not start complaining about a a
> couple of ICEs but rather be grateful that Richard's work exists :-).

- fully agree, and appreciate/admire Richard's effort, and sorry if it
appeared otherwise in the note I written after the build and experiment
finished at ~3:30am this morning before getting some sleep.

> You'll find enclosed an attachment where I have replaced the present patterns
> for sign- and zero- extension by define_expands and where the shifting
> instructions are largely replaced by expanders as well.
> IMO, one could try to use the infrastructure Richard's patch provides as a
> base for a complete re-work of the avr back end. Main remaining
> complications, IMO will be
> 1.) Re-using the condition codes for branching
> 2.) Teaching the mid-end algebra on "add-with-carry" "sub-with-carry"
> "compare-with-carry" operations.
> 3.) Identifying single-bit-test branches.
> 4.) Finding a way to continue to use movw as frequently as possible.
> 5.) Make sure that one could continue to use the addiw operations for the
> pointers.

- although the experiment results using the existing port was basic at best,
it actually seemed pretty good; as the predominant weirdness seems to be
resulting from an unusual sequence of logical casts potentially resulting
from the lowering optimization interacting with the existing expression
analysis logic?

> Most of these issues are somewhat related to condition code use and the
> cc0->CCmode issue.
> For 5.) one might consider to distinguish pointers from usual numbers by
> defining Pmode to be PHI instead of HI.

- I considered this, but pointer operations seem to remain their integrity?

> I'd also like to suggest to change the convention for __tmp_reg__ and
> __zero_reg__ so that these refer to r2:r3 instead of r0:r1 . This way, one
> could prevent unnecessary moves within the register file for the results of
> multiplications, avoid all of the permanent clr __zero_reg__ and shorten IRQ
> function prologues.

- or simply eliminate a hard 0 register entirely?

> Yours,
> Björn
> Btw.: As example code showing the potential you might look at the following
> function. It used to generate a function size of 43 with 3.4.3 and now ends
> up with a length of 16!
> #include <inttypes.h>
> uint32_t a;
> int16_t b;
> uint16_t 
> dummy (uint8_t x, uint32_t y)
> {   a = x;
>     b = ((uint16_t) (y >> 24)) | (x << 8);
>     return x | (y << 8);
> }

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]