This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, i386]: Fix PR 59021, new vzeroupper instructions generated with -mavx
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Joern Rennecke <joern dot rennecke at embecosm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Eric Botcazou <ebotcazou at adacore dot com>
- Date: Fri, 8 Nov 2013 10:07:04 +0100
- Subject: Re: [PATCH, i386]: Fix PR 59021, new vzeroupper instructions generated with -mavx
- Authentication-results: sourceware.org; auth=none
- References: <CAFULd4a2Y4QPfhAPOpF7dudkZR7U6qDmtBCuRSNUw_pSE+seaA at mail dot gmail dot com> <7340319 dot 7ogqOZmrEc at polaris> <CAFULd4ZtnyutbW_uQJX3M4u-Wt1-VkNqRxKudhxdN5Xz5NRZzg at mail dot gmail dot com> <CAFULd4Z5NkhXzRsPD4PXBmWvxK=hcHR3WXqOSdUQK+tn8TJqZQ at mail dot gmail dot com> <CAMqJFCoYWN6_kABzPR13fWHxsuqf9YZPrNwi4QL9d=EpuPC3hQ at mail dot gmail dot com>
On Fri, Nov 8, 2013 at 1:07 AM, Joern Rennecke
<joern.rennecke@embecosm.com> wrote:
> On 7 November 2013 20:01, Uros Bizjak <ubizjak@gmail.com> wrote:
>
>> OTOH, looking a bit deeper, it looks that there is a problem in
>> mode-switching infrastructure. If we have a BB without any mode
>> requirements, but an insn that switched the mode via MODE_AFTER, we
>> should not mark the block as transparent. Indeed, we even have a N.B.
>> comment in mode-switching.c:
>>
>> /* Check for blocks without ANY mode requirements.
>> N.B. because of MODE_AFTER, last_mode might still be different
>> from no_mode. */
>>
>> But, we do nothing w.r.t to transparency
>
> The optimize_mode_switching patch makes sense to me.
Thanks, I will propose a patch for this.
>> Attached incremental patch also fixes additional vzeroupper problem.
>> Calls with AVX argument register in fact do not have any mode
>> requirements, so we don't need to fake MODE_DIRTY requirement.
>
> Not sure about this - because I'm note sure what the meaning of values in
> avx_u128_state are. This lack of clarity is not caused by your patch,
> but is that something that could be reasonably be explained
> in a comment, or would that have to be too long to be helpful?
No problem here, these are state transitions for vzeroupper
mode-switching state. State should be changed to DIRTY by functions
that use AVX256 argument registers.
Best regards,
Uros.