> On Oct 1, 2020, at 11:20 AM, Richard Sandiford <richard.sandif...@arm.com>
> wrote:
>
> Qing Zhao <qing.z...@oracle.com> writes:
>> Hi, Richard,
>>
>> To answer the question, which registers should be included in “ALL”.
>> I studied X86 hard register set in more details. And also consulted with
>> H.J.Lu, And found:
>>
>> In the current x86 implementation, mask registers, MM0-MM7 registers, and
>> ST0-ST7 registers are not zeroed.
>>
>> The reasons actually are:
>> 1. Mask registers are marked as “FIXED_REGS” by middle end, (in the
>> following place, reginfo.c, init_reg_sets_1)
>>
>> /* If a register is too limited to be treated as a register operand,
>> then it should never be allocated to a pseudo. */
>> if (!TEST_HARD_REG_BIT (operand_reg_set, i))
>> fixed_regs[i] = 1;
>
> But isn't that only true when AVX512F is disabled?
>
> The question is more why the registers shouldn't be zeroed when
> they're available.
If they are not treated as fixed, then we should zeroed them.
>
>> 2. MM0-MM7 registers and ST0-ST7 registers are aliased with each other,
>> (i.e, the same set of registers have two different
>> Names), so, zero individual mm or st register will be very impractical.
>> However, we can zero them together with emms.
>
> Ah, OK.
>
>> So, my conclusion is,
>>
>> 1. For “ALL”, we should include all call_used_regs that are not fixed_regs.
>> 2. For X86 implementation, I added more comments, and also add clearing all
>> mm and st registers with emms.
>>
>> In general, “ALL” should include all call_used_regs that are not fixed_regs.
>
> Right. I thought the original implementation already excluded fixed
> registers, but perhaps I'm misremembering.
Yes, my current implementation in middle end already excluded fixed registers.
> I agree that that's the
> sensible default behaviour.
>
> Going back to the default hook, I guess one option is:
>
> rtx zero = CONST0_RTX (reg_raw_mode[regno]);
> rtx_insn *insn = emit_insn (gen_rtx_SET (regno_reg_rtx[regno], zero));
> if (!valid_insn_p (insn))
> sorry (…);
The valid_insn_p approach will exclude all FP registers for rs6000 as I
mentioned in the previous email, I don’t think that this is the right fix to
the rs6000 ICE.
I’d rather leave this problem there, and hopefully rs6000 developer can
override this issue very soon?
>
> but with some mechanism to avoid spewing the user with messages
> for the same problem.
>
> Thanks,
> Richard
