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] type promotion pass

On 09/15/2017 07:47 AM, Wilco Dijkstra wrote:
> David Edelsohn wrote:
>> Why does AArch64 define PROMOTE_MODE as SImode?  GCC ports for other
>> RISC targets mostly seem to use a 64-bit mode.  Maybe SImode is the
>> correct definition based on the current GCC optimization
>> infrastructure, but this seems like a change that should be applied to
>> all 64 bit RISC targets.
> The reason is that AArch64 supports both 32-bit registers, so when using char/short
> you want 32-bit operations. There is an issue in that WORD_REGISTER_OPERATIONS
> isn't set on AArch64, but it should be. Maybe that requires some cleanups and ensure it
> correctly interacts with PROMOTE_MODE. There are way too many confusing target
> defines like this and no general mechanism that just works like you'd expect. Promoting
> to an orthogonal set of registers is not something particularly unusual, so it's something
> GCC should support well by default...
Note this ties in directly with the conversation Steve and I have been
having in another thread.

WORD_REGISTER_OPERATIONS works with PROMOTE_MODE.  The reason you can't
define WORD_REGISTER_OPERATIONS on aarch64 is because that the implicit
promotion is sometimes to 32 bits and sometimes to 64 bits.
WORD_REGISTER_OPERATIONS can't really describe that.

Ideally the way forward is to address that limitation of
WORD_REGISTER_OPERATIONS which will eliminate a large number of zero

I also think improving REE would help -- in particular having it handle
subregs which are just another way of expressing an extension.  I
suspect that would also allow folding away a goodly amount of extensions.

And I'm also keen on doing something with type promotion -- Kai did some
work in this space years ago which I found interesting, even if the work
didn't go forward.  It showed a real weakness.  So I'm certainly
interested in looking at Prathamesh's work -- with the caveat that if it
stumbles across the same issues as Kai's work that it likely wouldn't be
acceptable in its current form.


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