On Wed, Aug 29, 2018 at 4:00 PM Alexander Monakov wrote:
>
> On Tue, 28 Aug 2018, Richard Biener wrote:
> > I think that if we want to support MULT_HIGHPART generally then we need
> > to support it for all modes - what's your plan for 32bit targets here? This
> > means providing libgcc fallback i
On Tue, 28 Aug 2018, Richard Biener wrote:
> I think that if we want to support MULT_HIGHPART generally then we need
> to support it for all modes - what's your plan for 32bit targets here? This
> means providing libgcc fallback implementations for modes we cannot directly
> expand to.
I didn't h
On Tue, Aug 28, 2018 at 7:59 AM Alexander Monakov wrote:
>
> > > > So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if
> > > > not supported?
>
> Richard, how should we proceed from here? Do you like the solution in the
> initial mail, or would you prefer something else? FWIW I
> > > So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if
> > > not supported?
Richard, how should we proceed from here? Do you like the solution in the
initial mail, or would you prefer something else? FWIW I agree with Pekka,
no need to burden BRIG FE with expanding mul-highp
Hi,
On Mon, Aug 20, 2018 at 1:46 PM Alexander Monakov wrote:
> > So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if
> > not supported?
>
> Pekka, can you comment? I think you have fallback paths for vector types
> only at the moment?
I think it involves pretty much moving the
On Mon, 20 Aug 2018, Richard Biener wrote:
> So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if
> not supported?
Pekka, can you comment? I think you have fallback paths for vector types
only at the moment?
Does BRIG have mult-highpart for 64-bit integers? On 32-bit targets we
On Fri, Aug 17, 2018 at 2:54 PM Alexander Monakov wrote:
>
> Hello,
>
> We currently have an unfortunate situation where, on the one hand, scalar
> MULT_HIGHPART_EXPR is usable only if the backend provides the corresponding
> pattern (otherwise ICEs in expand), but on the other hand, the BRIG fron
Hello,
We currently have an unfortunate situation where, on the one hand, scalar
MULT_HIGHPART_EXPR is usable only if the backend provides the corresponding
pattern (otherwise ICEs in expand), but on the other hand, the BRIG frontend
wants to make use of it.
I think BRIG FE is making assumptions
