diff options
| author | Hal Finkel <hfinkel@anl.gov> | 2014-10-04 15:26:49 +0000 |
|---|---|---|
| committer | Hal Finkel <hfinkel@anl.gov> | 2014-10-04 15:26:49 +0000 |
| commit | 64567a80d20ec5489e988c176ead2efacac184ed (patch) | |
| tree | aeeac2571364e54934441f626734cd0ac0569354 /clang/lib/CodeGen/CGExprScalar.cpp | |
| parent | 936675e281dce21e45969ca0eff2a063ef430a37 (diff) | |
| download | bcm5719-llvm-64567a80d20ec5489e988c176ead2efacac184ed.tar.gz bcm5719-llvm-64567a80d20ec5489e988c176ead2efacac184ed.zip | |
Emit @llvm.assume for non-parameter lvalue align_value-attribute loads
We already add the align parameter attribute for function parameters that have
the align_value attribute (or those with a typedef type having that attribute),
which is an important special case, but does not handle pointers with value
alignment assumptions that come into scope in any other way. To handle the
general case, emit an @llvm.assume-based alignment assumption whenever we load
the pointer-typed lvalue of an align_value-attributed variable (except for
function parameters, which we already deal with at entry).
I'll also note that this is more general than Intel's described support in:
https://software.intel.com/en-us/articles/data-alignment-to-assist-vectorization
which states that the compiler inserts __assume_aligned directives in response
to align_value-attributed variables only for function parameters and for the
initializers of local variables. I think that we can make the optimizer deal
with this more-general scheme (which could lead to a lot of calls to
@llvm.assume inside of loop bodies, for example), but if not, I'll rework this
to be less aggressive.
llvm-svn: 219052
Diffstat (limited to 'clang/lib/CodeGen/CGExprScalar.cpp')
| -rw-r--r-- | clang/lib/CodeGen/CGExprScalar.cpp | 44 |
1 files changed, 41 insertions, 3 deletions
diff --git a/clang/lib/CodeGen/CGExprScalar.cpp b/clang/lib/CodeGen/CGExprScalar.cpp index 207f98f85f1..abde51f29e4 100644 --- a/clang/lib/CodeGen/CGExprScalar.cpp +++ b/clang/lib/CodeGen/CGExprScalar.cpp @@ -91,12 +91,47 @@ public: return CGF.EmitLoadOfLValue(LV, Loc).getScalarVal(); } + void EmitLValueAlignmentAssumption(const Expr *E, Value *V) { + const AlignValueAttr *AVAttr = nullptr; + if (const auto *DRE = dyn_cast<DeclRefExpr>(E)) { + const ValueDecl *VD = DRE->getDecl(); + + if (VD->getType()->isReferenceType()) { + if (const auto *TTy = + dyn_cast<TypedefType>(VD->getType().getNonReferenceType())) + AVAttr = TTy->getDecl()->getAttr<AlignValueAttr>(); + } else { + // Assumptions for function parameters are emitted at the start of the + // function, so there is no need to repeat that here. + if (isa<ParmVarDecl>(VD)) + return; + + AVAttr = VD->getAttr<AlignValueAttr>(); + } + } + + if (!AVAttr) + if (const auto *TTy = + dyn_cast<TypedefType>(E->getType())) + AVAttr = TTy->getDecl()->getAttr<AlignValueAttr>(); + + if (!AVAttr) + return; + + Value *AlignmentValue = CGF.EmitScalarExpr(AVAttr->getAlignment()); + llvm::ConstantInt *AlignmentCI = cast<llvm::ConstantInt>(AlignmentValue); + CGF.EmitAlignmentAssumption(V, AlignmentCI->getZExtValue()); + } + /// EmitLoadOfLValue - Given an expression with complex type that represents a /// value l-value, this method emits the address of the l-value, then loads /// and returns the result. Value *EmitLoadOfLValue(const Expr *E) { - return EmitLoadOfLValue(EmitCheckedLValue(E, CodeGenFunction::TCK_Load), - E->getExprLoc()); + Value *V = EmitLoadOfLValue(EmitCheckedLValue(E, CodeGenFunction::TCK_Load), + E->getExprLoc()); + + EmitLValueAlignmentAssumption(E, V); + return V; } /// EmitConversionToBool - Convert the specified expression value to a @@ -286,7 +321,10 @@ public: if (E->getCallReturnType()->isReferenceType()) return EmitLoadOfLValue(E); - return CGF.EmitCallExpr(E).getScalarVal(); + Value *V = CGF.EmitCallExpr(E).getScalarVal(); + + EmitLValueAlignmentAssumption(E, V); + return V; } Value *VisitStmtExpr(const StmtExpr *E); |

