On Wed, Mar 24, 2021 at 7:46 AM Alexandre Oliva wrote:
>
> Hello, Jakub,
>
> On Mar 19, 2021, Jakub Jelinek wrote:
>
> > On Fri, Mar 19, 2021 at 07:44:01PM -0300, Alexandre Oliva wrote:
>
> >> However, I had a total of 15 similar fails within gcc.target/i386 in a
> >> gcc-10 tree configured with
Hello, Jakub,
On Mar 19, 2021, Jakub Jelinek wrote:
> On Fri, Mar 19, 2021 at 07:44:01PM -0300, Alexandre Oliva wrote:
>> However, I had a total of 15 similar fails within gcc.target/i386 in a
>> gcc-10 tree configured with -mcmodel=large
> But then we should add at least one new testcase for
On Fri, Mar 19, 2021 at 07:44:01PM -0300, Alexandre Oliva wrote:
> > Testcase?
>
> Uhh, sorry I failed to mention that.
>
> gcc.target/i386/pr94467-1.c was what I used (with -mcmodel=large) to
> duplicate the problem and then confirm the fix in the trunk.
>
> However, I had a total of 15 similar
On Mar 19, 2021, Uros Bizjak wrote:
>> * config/i386/predicates.md (register_or_const_vec_operand):
>> New.
>> * config/i386/sse.md (ssse3_pshufbv8qi3): Add an expander for
>> the now *-prefixed insn_and_split, turn the splitter const vec
>> into an input for the insn, making it an ignored immedi
On Fri, Mar 19, 2021 at 7:29 AM Alexandre Oliva wrote:
>
>
> The split in ssse3_pshufbv8qi3 forces a const vector into the constant
> pool, and loads from it. That runs after reload, so if the load
> requires any reloading, we're out of luck. Indeed, if the load
> address is not legitimate, e.g.
