On Tue, 3 Oct 2023, Martin Jambor wrote:
> > SSA graph may be deep so this may cause stack overflow, so I think we
> > should use worklist here (it is also easy to do).
> >
> > OK with that change.
> > Honza
>
> I have just committed the following after a bootstrap and testing on
> x86_64-linux.
On Wed, Oct 4, 2023 at 5:08 PM Maciej W. Rozycki wrote:
>
> On Tue, 3 Oct 2023, Martin Jambor wrote:
>
> > > SSA graph may be deep so this may cause stack overflow, so I think we
> > > should use worklist here (it is also easy to do).
> > >
> > > OK with that change.
> > > Honza
> >
> > I have jus
Hi,
As mentioned in PR108338, on p9, we could use mtvsrws to implement
the bitcast from SI to SF (or lowpart DI to SF).
For example:
*(long long*)buff = di;
float f = *(float*)(buff);
"sldi 9,3,32 ; mtvsrd 1,9 ; xscvspdpn 1,1" is generated.
A better one would be "mtvsrws 1,3 ; xscvspdpn 1,1"
On 9/28/23 15:43, Vineet Gupta wrote:
RISC-V suffers from extraneous sign extensions, despite/given the ABI
guarantee that 32-bit quantities are sign-extended into 64-bit registers,
meaning incoming SI function args need not be explicitly sign extended
(so do SI return values as most ALU insns
Hi,
Currently, we have the pattern "movsf_from_si2" which was trying
to support moving high part DI to SF.
But current pattern only accepts "ashiftrt":
XX:SF=bitcast:SF(subreg(YY:DI>>32),0), but actually "lshiftrt" should
also be ok.
And current pattern only supports BE.
This patch updats the pa
On Wed, 2023-10-04 at 23:19 +0100, Roger Sayle wrote:
>
> The recent patch to remove poly_int_pod triggers a bug in g++ 4.8.5's
> C++ 11 support which mistakenly believes poly_uint16 has a non-trivial
> constructor. This in turn prohibits it from being used as a member in
> a union (rtxunion) tha
101 - 106 of 106 matches
Mail list logo
