This is an archive of the discontinued LLVM Phabricator instance.

[x86, AVX] don't add a vzeroupper if that's what the code is already doing (PR27823)
ClosedPublic

Authored by spatel on May 20 2016, 10:42 AM.

Details

Summary

This isn't the complete fix, but it handles the trivial examples of duplicate vzero* ops in PR27823:
https://llvm.org/bugs/show_bug.cgi?id=27823
...and amusingly, the bogus cases already exist as regression tests, so let's take this baby step.

We'll need to do more in the general case where there's legitimate AVX usage in the function + there's already a vzero in the code.

Diff Detail

Repository
rL LLVM

Event Timeline

spatel updated this revision to Diff 57953.May 20 2016, 10:42 AM
spatel retitled this revision from to [x86, AVX] don't add a vzeroupper if that's what the code is already doing (PR27823).
spatel updated this object.
spatel added reviewers: RKSimon, aaboud, ygao.
spatel added a subscriber: llvm-commits.
RKSimon edited edge metadata.May 21 2016, 2:38 PM

Can we add tests for explicit calls to vzeroall/vzeroupper that is half way through the function with ymm accesses before + after?

aaboud accepted this revision.May 22 2016, 3:47 AM
aaboud edited edge metadata.

LGTM.
+1 for adding the test Simon mentioned.

This revision is now accepted and ready to land.May 22 2016, 3:47 AM

Can we add tests for explicit calls to vzeroall/vzeroupper that is half way through the function with ymm accesses before + after?

Thanks, Simon and Amjad.
I'm not sure of all of the cases that we need to handle, but I've started a file for that purpose with:
rL270375
That's a simplification of the example I noted in:
https://llvm.org/bugs/show_bug.cgi?id=27823#c3

I'll add a FIXME comment to this patch, so we know that this is not the complete solution.

This revision was automatically updated to reflect the committed changes.