Robin Dapp writes:
>> However:
>>
>> | #define vec_extract_direct { 3, 3, false }
>>
>> This looks wrong. The numbers are argument numbers (or -1 for a return
>> value). vec_extract only takes 2 arguments, so 3 looks to be out-of-range.
>>
>> | #define direct_vec_extract_optab_supported_p dir
> However:
>
> | #define vec_extract_direct { 3, 3, false }
>
> This looks wrong. The numbers are argument numbers (or -1 for a return
> value). vec_extract only takes 2 arguments, so 3 looks to be out-of-range.
>
> | #define direct_vec_extract_optab_supported_p direct_optab_supported_p
>
> I
"juzhe.zh...@rivai.ai" writes:
> Hi, Robin, Richard and Richi.
>
> I am wondering whether we can just simply replace the VEC_EXTRACT expander
> with binary?
>
> Like this :?
>
> DEF_INTERNAL_OPTAB_FN (VEC_EXTRACT, ECF_CONST | ECF_NOTHROW,
> - vec_extract, vec_extract)
> + vec_ex
Hi, Robin, Richard and Richi.
I am wondering whether we can just simply replace the VEC_EXTRACT expander with
binary?
Like this :?
DEF_INTERNAL_OPTAB_FN (VEC_EXTRACT, ECF_CONST | ECF_NOTHROW,
- vec_extract, vec_extract)
+ vec_extract, binary)
to fix the sign extend issue.
An
Hi,
this patch fixes the case where vec_extract gets passed a promoted
subreg (e.g. from a return value). When such a subreg is the
destination of a vector extraction we create a separate pseudo
register and ensure that the necessary promotion is performed
afterwards.
Before this patch a sign-ex
