On Tue, 1 Sep 2020, Jakub Jelinek wrote:
> On Tue, Sep 01, 2020 at 01:52:21PM +0200, Richard Biener wrote:
> > OK, I'll see to do that (or fixup the RTL expansion side somehow).
> >
> > Note that clang and gcc disagree about the return value ABI for
> >
> > typedef double v1df __attribute__((vec
On Tue, Sep 01, 2020 at 01:52:21PM +0200, Richard Biener wrote:
> OK, I'll see to do that (or fixup the RTL expansion side somehow).
>
> Note that clang and gcc disagree about the return value ABI for
>
> typedef double v1df __attribute__((vector_size(8)));
>
> v1df foo (v1df x)
> {
> return x
On Tue, 1 Sep 2020, Jakub Jelinek wrote:
> On Tue, Sep 01, 2020 at 11:50:32AM +0200, Richard Biener wrote:
> > While IMHO it makes very much sense to map V1{S,D,T}F types
> > to {S,D,T}Fmode if there's no special vector mode for it the
> > question is whether we can make this "change" for the sake
On Tue, 1 Sep 2020, Jakub Jelinek via Gcc-patches wrote:
On Tue, Sep 01, 2020 at 11:50:32AM +0200, Richard Biener wrote:
While IMHO it makes very much sense to map V1{S,D,T}F types
to {S,D,T}Fmode if there's no special vector mode for it the
question is whether we can make this "change" for the
On Tue, Sep 01, 2020 at 11:50:32AM +0200, Richard Biener wrote:
> While IMHO it makes very much sense to map V1{S,D,T}F types
> to {S,D,T}Fmode if there's no special vector mode for it the
> question is whether we can make this "change" for the sake
> of the ABIs? The alternative is to make vector
This maps single-element vectors to the component mode when the
single-element vector mode is not available. This is what happens
for integer element modes already via mapping to a same-sized
scalar mode (which also covers multi-element vectors).
This avoids ICEing when expanding bit-inserts of s
