This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH] AVR: implement HI/SI logic operations and sign/zeroextension by define_insn_and_split ...


> From: Björn Haase <bjoern.m.haase@web.de>
>>> My tests have shown that when using the splitters, code gets considerably
>>> better for complex logic operations. For my real-world application of
>>> 16k, I have observed about 50 bytes smaller code.
>> 
>> - Do you suspect that most of these benefits would be preserved if for
>>   example both QI and HI mode operations were optimally coded, thereby both
>>   being able to preserved the visibility the few word (HI) mode operations
>>   the avr is capable of natively, and then correspondingly splitting SI/DI
>>   mode operations into them as required (as opposed to all the way to QI
>>   mode initially? given that C defaults to wanting to turn everything into
>>   int operations by default, which corresponds to HI mode on the avr?)

Hi Björn,

> the main benefit is, that expressions like
> 
> uint16_t a;
> 
> a  |= 0xF503
> a &= 0xFF00
> 
> will now yield two asm instructions, e.g.
> 
> ldi r24,0
> ori r25,0xF5

- very nice.

> So it will help also when always using the appropriate type. It will be even
> better, once one starts to split also arithmetics (sub, add, mul), moves and
> shifts.

- might splitting SI/DI mode operations down to HI mode prior to reload
  both enable the word oriented instructions addw/subw/movw/mul(word result)
  to be leveraged while also providing more register allocation flexibility
  for function calls etc, and then conditionally spit further after reload
  insertion if determined to be beneficial (as I guess I don't understand
  how once an HI mode add is split, it can easily be re-joined to leverage
  an add word instruction for example if the required registers are
  available, but not otherwise?)



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