This is an archive of the discontinued LLVM Phabricator instance.

[CodeGen] Teach X86_64ABIInfo about AVX512.
ClosedPublic

Authored by ab on May 20 2015, 1:56 PM.

Details

Summary

Tentative but straightforward patch, based on the "Edited for AVX512" SysV ABI drafts.

Depends on a local refactoring to pass the ABI string rather than HasAVX.

Diff Detail

Repository
rL LLVM

Event Timeline

ab updated this revision to Diff 26179.May 20 2015, 1:56 PM
ab retitled this revision from to [CodeGen] Teach X86_64ABIInfo about AVX512..
ab updated this object.
ab edited the test plan for this revision. (Show Details)
ab added a reviewer: rjmccall.
ab added a subscriber: Unknown Object (MLST).
ab added inline comments.May 20 2015, 1:59 PM
lib/CodeGen/TargetInfo.cpp
1634–1635 ↗(On Diff #26179)

This I'm not sure; it makes sense to me to align to 64 when we have AVX512.

There's also the WinX86_64 counterpart, which I'm even less confident about.

rjmccall added inline comments.
lib/CodeGen/TargetInfo.cpp
1634–1635 ↗(On Diff #26179)

I am pretty skeptical of even the original code here, frankly. Are clients really making stronger promises just because they're compiling with AVX enabled? Note that the compiler doesn't *do* anything to achieve this; it literally just makes a more aggressive assumption about what the user has done.

It seems to me like the (1) the OpenMP people ought to review this and seriously consider it and (2) this number needs to be available to code in some portable manner, probably via a predefined macro. Which means it probably ought to be defined in the AST-level TargetInfo. CC'ing Alexey Bataev.

1934 ↗(On Diff #26179)

Please parenthesize this second ||. It's actually wrong as written: && binds tighter than ||, but you want isNamedArg to apply to both.

ABataev added inline comments.May 21 2015, 1:01 AM
lib/CodeGen/TargetInfo.cpp
1634–1635 ↗(On Diff #26179)

John, here is an excerpt from the OpenMP "If no optional parameter is specified, implementation-defined default
alignments for SIMD instructions on the target platforms are assumed." So, the value can be chosen by the compiler. But I think it is a good idea to have a macro for this.

rjmccall added inline comments.May 21 2015, 9:48 AM
lib/CodeGen/TargetInfo.cpp
1634–1635 ↗(On Diff #26179)

Okay. Would you mind making sure that happens? In the meantime, I think we should bump the alignment up to 64 here when AVX512 is enabled.

ABataev edited edge metadata.May 21 2015, 7:57 PM

No problems

Best regards,

Alexey Bataev

Software Engineer
Intel Compiler Team

21.05.2015 19:48, John McCall пишет:

Comment at: lib/CodeGen/TargetInfo.cpp:1634-1635
@@ -1630,3 +1633,4 @@

unsigned getOpenMPSimdDefaultAlignment(QualType) const override {

+ // FIXME: What about AVX512?

  return getABIInfo().hasAVX() ? 32 : 16;
}

ABataev wrote:

rjmccall wrote:

ab wrote:

This I'm not sure; it makes sense to me to align to 64 when we have AVX512.

There's also the WinX86_64 counterpart, which I'm even less confident about.

I am pretty skeptical of even the original code here, frankly. Are clients really making stronger promises just because they're compiling with AVX enabled? Note that the compiler doesn't *do* anything to achieve this; it literally just makes a more aggressive assumption about what the user has done.

It seems to me like the (1) the OpenMP people ought to review this and seriously consider it and (2) this number needs to be available to code in some portable manner, probably via a predefined macro. Which means it probably ought to be defined in the AST-level TargetInfo. CC'ing Alexey Bataev.

John, here is an excerpt from the OpenMP "If no optional parameter is specified, implementation-defined default
alignments for SIMD instructions on the target platforms are assumed." So, the value can be chosen by the compiler. But I think it is a good idea to have a macro for this.

Okay. Would you mind making sure that happens? In the meantime, I think we should bump the alignment up to 64 here when AVX512 is enabled.

http://reviews.llvm.org/D9894

EMAIL PREFERENCES

http://reviews.llvm.org/settings/panel/emailpreferences/
ab updated this revision to Diff 26332.May 22 2015, 11:01 AM
ab edited edge metadata.
  • Add OpenMP default alignment for AVX512
  • Extract HasAVX/HasAVX512 into a X86_64BaseABIInfo

In r237989 I refactored the "HasAVX" flag to just use the TargetInfo::getABI() string, but I'm tempted to revert, and pass down an additional HasAVX512 flag. I originally wanted to do the same thing for other targets, but didn't realize that some of the ABIs depend on things not in TargetInfo, e.g. CodeGenOptions, which aren't supposed to be available?

Anyway, opinions welcome, one way or the other.

rjmccall edited edge metadata.Jun 18 2015, 12:25 AM

I like the idea of passing it down instead of working off of strings. Maybe pass down an enum instead of two flags?

Hi John,
tried to add a macro for default alignment, but it does not work. Method
getOpenMPSimdDefaultAlignment() has a parameter QualType, which used for
some specific targets and makes this method to return different default
alignment for different types on some platforms (for example, for
PPC64_SVR4. So you can't just create a single macro with the predefined
value that could be used for all types.

Best regards,

Alexey Bataev

Software Engineer
Intel Compiler Team

18.06.2015 10:25, John McCall пишет:

I like the idea of passing it down instead of working off of strings. Maybe pass down an enum instead of two flags?

http://reviews.llvm.org/D9894

EMAIL PREFERENCES

http://reviews.llvm.org/settings/panel/emailpreferences/

Okay, that gives us two options. The first is to use a macro that's conservative for all types; the second is to add a new type trait. If the performance difference on PPC64 is important, the type trait seems fine to me.

I guess it would have to be a UnaryExprOrTypeTrait, because the unary type traits don't currently allow returning size_t.

ab updated this revision to Diff 27987.Jun 18 2015, 6:42 PM
ab edited edge metadata.
  • Use an AVXLevel enum
  • Deduplicate AVXLevel -> size pattern

With that, adding AVX512 support is a trivial 4 line patch.

This revision was automatically updated to reflect the committed changes.