This is the mail archive of the gcc@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: help for arm avr bfin cris frv h8300 m68k mcore mmix pdp11 rs6000 sh vax


Martin Guy wrote:
> On 3/14/09, Paolo Bonzini <bonzini@gnu.org> wrote:
>> Hans-Peter Nilsson wrote:
>>  > The answer to the question is "no", but I'd guess the more
>>  > useful answer is "yes", for different definitions of "truncate".
>>
>> Ok, after my patches you will be able to teach GCC about this definition
>>  of truncate.
> 
> I expect it's a bit too extreme an example, but I've just found (to my
> horror) that the MaverickCrunch FPU truncates all its shift counts to
> 6-bit signed (-32(right) to +31(left)), including on 64-bit integers,
> which is not very helpful to compile for.
> ...unless it happens to come easy to handle "shift count is truncated
> to less than size of word" in your new framework

Uhm, well, no. :-)

This could already be handled by faking a 63 bit truncation and using a
splitter to expand those into something like this (I only know integer
ARM assembly, so I'm making this up):

   AND R1, R0, #31
   MOV R2, R2, SHIFT R1
   ANDS R1, R0, #32
   MOVNE R2, R2, SHIFT #31
   MOVNE R2, R2, SHIFT #1

or

   ANDS R1, R0, #32
   MOVNE R2, R2, SHIFT #-32
   SUB R1, R1, R0              ; R1 = (x >= 32 ? 32 - x : -x)
   MOV R2, R2, SHIFT R1

(which requires a scratch register, so it cannot be done postreload...
this might be a problem)

But my new stuff won't change anything.

Paolo


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