maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/CodeGen/CGExpr.cpp

3977 lines
153 KiB
C++
Raw Normal View History

split stmt/expr codegen into their own files. llvm-svn: 39540
2007-06-02 02:02:12 +08:00
//===--- CGExpr.cpp - Emit LLVM Code from Expressions ---------------------===//
//
// The LLVM Compiler Infrastructure
//
Don't attribute in file headers anymore. See llvmdev for the discussion of this change. llvm-svn: 45410
2007-12-30 03:59:25 +08:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
split stmt/expr codegen into their own files. llvm-svn: 39540
2007-06-02 02:02:12 +08:00
//
//===----------------------------------------------------------------------===//
//
// This contains code to emit Expr nodes as LLVM code.
//
//===----------------------------------------------------------------------===//
#include "CodeGenFunction.h"
Teach IR generation to return 'this' from constructors and destructors under the ARM ABI. llvm-svn: 112588
2010-08-31 15:33:07 +08:00
#include "CGCXXABI.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "CGCall.h"
Emit a stop point before a call expression so that debugger has some chance of getting some footing when user wants to stop at 2nd bar() in following expression when all function calls are inlined. = bar() + ... + bar() + ... clang keeps track of column numbers, so we could put location entries for all subexpressions but that will significantly bloat debug info in general, but a location for call expression is helpful here. llvm-svn: 127018
2011-03-05 02:54:42 +08:00
#include "CGDebugInfo.h"
Change ObjCRuntime GenerateProtocol[Ref] methods to take ObjCProtocolDecl directly. Implement CodeGen support for forward protocol decls (no-ops are so nice to implement). Also moved CGObjCRuntime.h out of CodeGenModule.h llvm-svn: 54709
2008-08-13 08:59:25 +08:00
#include "CGObjCRuntime.h"
[OPENMP] Codegen for threadprivate variables For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
2014-11-11 12:05:39 +08:00
#include "CGOpenMPRuntime.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "CGRecordLayout.h"
#include "CodeGenModule.h"
ANSI C requires that a call to an unprototyped function type succeed if the definition has a non-variadic prototype with compatible parameters. Therefore, the default rule for such calls must be to use a non-variadic convention. Achieve this by casting the callee to the function type with which it is required to be compatible, unless the target specifically opts out and insists that unprototyped calls should use the variadic rules. The only case of that I'm aware of is the x86-64 convention, which passes arguments the same way in both cases but also sets a small amount of extra information; here we seek to maintain compatibility with GCC, which does set this when calling an unprototyped function. Addresses PR10810 and PR10713. llvm-svn: 140241
2011-09-21 16:08:30 +08:00
#include "TargetInfo.h"
More #include cleaning - Remove internal uses of AST.h llvm-svn: 54628
2008-08-11 13:00:27 +08:00
#include "clang/AST/ASTContext.h"
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
#include "clang/AST/Attr.h"
[cleanup] Re-sort *all* #include lines with llvm/utils/sort_includes.py Sorry for the noise, I managed to miss a bunch of recent regressions of include orderings here. This should actually sort all the includes for Clang. Again, no functionality changed, this is just a mechanical cleanup that I try to run periodically to keep the #include lines as regular as possible across the project. llvm-svn: 225979
2015-01-14 19:29:14 +08:00
#include "clang/AST/DeclObjC.h"
Move CodeGenOptions.h *back* into Frontend. This should have been done when the dependency edge was reversed such that CodeGen depends on Frontend. llvm-svn: 106065
2010-06-16 07:19:56 +08:00
#include "clang/Frontend/CodeGenOptions.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "llvm/ADT/Hashing.h"
Fix for bug http://llvm.org/PR17427. Assertion failed: "Computed __func__ length differs from type!" Reworked PredefinedExpr representation with internal StringLiteral field for function declaration. Differential Revision: http://reviews.llvm.org/D5365 llvm-svn: 219393
2014-10-09 16:45:04 +08:00
#include "llvm/ADT/StringExtras.h"
Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate to reflect the migration in r171366. Re-sort the #include lines to reflect the new paths. llvm-svn: 171369
2013-01-02 19:45:17 +08:00
#include "llvm/IR/DataLayout.h"
#include "llvm/IR/Intrinsics.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/MDBuilder.h"
Move UTF conversion routines from clang/lib/Basic to llvm/lib/Support This is required to use them in TableGen. llvm-svn: 173924
2013-01-30 20:06:08 +08:00
#include "llvm/Support/ConvertUTF.h"
Unify sanitizer kind representation between the driver and the rest of the compiler. No functional change. Differential Revision: http://reviews.llvm.org/D9618 llvm-svn: 237055
2015-05-12 05:39:14 +08:00
#include "llvm/Support/MathExtras.h"
Move UTF conversion routines from clang/lib/Basic to llvm/lib/Support This is required to use them in TableGen. llvm-svn: 173924
2013-01-30 20:06:08 +08:00
split stmt/expr codegen into their own files. llvm-svn: 39540
2007-06-02 02:02:12 +08:00
using namespace clang;
using namespace CodeGen;
Refactor EvaluateScalarValueToBool out of if statement emission, so it can be shared. Implement infrastructure for unary operator emission. Implement basic logical not support. We now compile: register short X; if (!X) { into: %tmp = load i16* %X ; <i16> [#uses=1] %tobool = icmp ne i16 %tmp, 0 ; <i1> [#uses=1] %lnot = xor i1 %tobool, true ; <i1> [#uses=1] zext i1 %lnot to i32 ; <i32>:0 [#uses=1] %tobool1 = icmp ne i32 %0, 0 ; <i1> [#uses=1] br i1 %tobool1, label %ifthen, label %ifend llvm-svn: 39559
2007-06-03 03:33:17 +08:00
//===--------------------------------------------------------------------===//
// Miscellaneous Helper Methods
//===--------------------------------------------------------------------===//
Reorganize CodeGen{Function,Module} to eliminate the unfortunate Block{Function,Module} base class. Minor other refactorings. Fixed a few address-space bugs while I was there. llvm-svn: 125085
2011-02-08 16:22:06 +08:00
llvm::Value *CodeGenFunction::EmitCastToVoidPtr(llvm::Value *value) {
unsigned addressSpace =
cast<llvm::PointerType>(value->getType())->getAddressSpace();
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::PointerType *destType = Int8PtrTy;
Reorganize CodeGen{Function,Module} to eliminate the unfortunate Block{Function,Module} base class. Minor other refactorings. Fixed a few address-space bugs while I was there. llvm-svn: 125085
2011-02-08 16:22:06 +08:00
if (addressSpace)
destType = llvm::Type::getInt8PtrTy(getLLVMContext(), addressSpace);
if (value->getType() == destType) return value;
return Builder.CreateBitCast(value, destType);
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
/// CreateTempAlloca - This creates a alloca and inserts it into the entry
/// block.
Address CodeGenFunction::CreateTempAlloca(llvm::Type *Ty, CharUnits Align,
const Twine &Name) {
auto Alloca = CreateTempAlloca(Ty, Name);
Alloca->setAlignment(Align.getQuantity());
return Address(Alloca, Align);
}
add some infrastructure for codegen'ing complex numbers. implement addition of complex. We now produce optimal code for: void test(_Complex float *Y) { *Y = *Y + *Y; } $ clang -emit-llvm cg.c | llvm-as | opt -std-compile-opts | llc -march=x86-64 ... _test: movss (%rdi), %xmm0 addss %xmm0, %xmm0 movss 4(%rdi), %xmm1 movss %xmm0, (%rdi) addss %xmm1, %xmm1 movss %xmm1, 4(%rdi) ret llvm-svn: 39673
2007-06-23 05:44:33 +08:00
/// CreateTempAlloca - This creates a alloca and inserts it into the entry
/// block.
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::AllocaInst *CodeGenFunction::CreateTempAlloca(llvm::Type *Ty,
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
const Twine &Name) {
fix CreateTempAlloca to not set a name on the alloca for temporaries in release-assert builds. For automatic variables, explicitly set a name with setName that does not make a temporary std::string. This speeds up -emit-llvm-only -disable-free on PR3810 by 4.6% llvm-svn: 67459
2009-03-22 08:24:14 +08:00
if (!Builder.isNamePreserving())
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
return new llvm::AllocaInst(Ty, nullptr, "", AllocaInsertPt);
return new llvm::AllocaInst(Ty, nullptr, Name, AllocaInsertPt);
add some infrastructure for codegen'ing complex numbers. implement addition of complex. We now produce optimal code for: void test(_Complex float *Y) { *Y = *Y + *Y; } $ clang -emit-llvm cg.c | llvm-as | opt -std-compile-opts | llc -march=x86-64 ... _test: movss (%rdi), %xmm0 addss %xmm0, %xmm0 movss 4(%rdi), %xmm1 movss %xmm0, (%rdi) addss %xmm1, %xmm1 movss %xmm1, 4(%rdi) ret llvm-svn: 39673
2007-06-23 05:44:33 +08:00
}
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
/// CreateDefaultAlignTempAlloca - This creates an alloca with the
/// default alignment of the corresponding LLVM type, which is *not*
/// guaranteed to be related in any way to the expected alignment of
/// an AST type that might have been lowered to Ty.
Address CodeGenFunction::CreateDefaultAlignTempAlloca(llvm::Type *Ty,
const Twine &Name) {
CharUnits Align =
CharUnits::fromQuantity(CGM.getDataLayout().getABITypeAlignment(Ty));
return CreateTempAlloca(Ty, Align, Name);
}
void CodeGenFunction::InitTempAlloca(Address Var, llvm::Value *Init) {
assert(isa<llvm::AllocaInst>(Var.getPointer()));
auto *Store = new llvm::StoreInst(Init, Var.getPointer());
Store->setAlignment(Var.getAlignment().getQuantity());
Call PerformCopyInitialization to properly initialize the exception temporary in a throw expression. Use EmitAnyExprToMem to emit the throw expression, which magically elides the final copy-constructor call (which raises a new strict-compliance bug, but baby steps). Give __cxa_throw a destructor pointer if the exception type has a non-trivial destructor. llvm-svn: 102039
2010-04-22 09:10:34 +08:00
llvm::BasicBlock *Block = AllocaInsertPt->getParent();
Block->getInstList().insertAfter(&*AllocaInsertPt, Store);
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address CodeGenFunction::CreateIRTemp(QualType Ty, const Twine &Name) {
IRgen: Add CreateIRTemp, which creates a temporary alloca but with type converted "not-for-memory". Dunno a better name. llvm-svn: 96374
2010-02-17 03:44:13 +08:00
CharUnits Align = getContext().getTypeAlignInChars(Ty);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return CreateTempAlloca(ConvertType(Ty), Align, Name);
IRgen: Add CreateIRTemp, which creates a temporary alloca but with type converted "not-for-memory". Dunno a better name. llvm-svn: 96374
2010-02-17 03:44:13 +08:00
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address CodeGenFunction::CreateMemTemp(QualType Ty, const Twine &Name) {
IRgen: Add CreateMemTemp, for creating an temporary memory object for a particular type, and flood fill. - CreateMemTemp sets the alignment on the alloca correctly, which fixes a great many places in IRgen where we were doing the wrong thing. - This fixes many many more places than the test case, but my feeling is we need to audit alignment systematically so I'm not inclined to try hard to test the individual fixes in this patch. If this bothers you, patches welcome! PR6240. llvm-svn: 95648
2010-02-09 10:48:28 +08:00
// FIXME: Should we prefer the preferred type alignment here?
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return CreateMemTemp(Ty, getContext().getTypeAlignInChars(Ty), Name);
}
Address CodeGenFunction::CreateMemTemp(QualType Ty, CharUnits Align,
const Twine &Name) {
return CreateTempAlloca(ConvertTypeForMem(Ty), Align, Name);
IRgen: Add CreateMemTemp, for creating an temporary memory object for a particular type, and flood fill. - CreateMemTemp sets the alignment on the alloca correctly, which fixes a great many places in IRgen where we were doing the wrong thing. - This fixes many many more places than the test case, but my feeling is we need to audit alignment systematically so I'm not inclined to try hard to test the individual fixes in this patch. If this bothers you, patches welcome! PR6240. llvm-svn: 95648
2010-02-09 10:48:28 +08:00
}
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
/// EvaluateExprAsBool - Perform the usual unary conversions on the specified
/// expression and compare the result against zero, returning an Int1Ty value.
Finally bite the bullet and make the major change: split the clang namespace out of the llvm namespace. This makes the clang namespace be a sibling of llvm instead of being a child. The good thing about this is that it makes many things unambiguous. The bad things is that many things in the llvm namespace (notably data structures like smallvector) now require an llvm:: qualifier. IMO, libsystem and libsupport should be split out of llvm into their own namespace in the future, which will fix this issue. llvm-svn: 39659
2007-06-16 07:05:46 +08:00
llvm::Value *CodeGenFunction::EvaluateExprAsBool(const Expr *E) {
Change PGO instrumentation to compute counts in a separate AST traversal. Previously, we made one traversal of the AST prior to codegen to assign counters to the ASTs and then propagated the count values during codegen. This patch now adds a separate AST traversal prior to codegen for the -fprofile-instr-use option to propagate the count values. The counts are then saved in a map from which they can be retrieved during codegen. This new approach has several advantages: 1. It gets rid of a lot of extra PGO-related code that had previously been added to codegen. 2. It fixes a serious bug. My original implementation (which was mailed to the list but never committed) used 3 counters for every loop. Justin improved it to move 2 of those counters into the less-frequently executed breaks and continues, but that turned out to produce wrong count values in some cases. The solution requires visiting a loop body before the condition so that the count for the condition properly includes the break and continue counts. Changing codegen to visit a loop body first would be a fairly invasive change, but with a separate AST traversal, it is easy to control the order of traversal. I've added a testcase (provided by Justin) to make sure this works correctly. 3. It improves the instrumentation overhead, reducing the number of counters for a loop from 3 to 1. We no longer need dedicated counters for breaks and continues, since we can just use the propagated count values when visiting breaks and continues. To make this work, I needed to make a change to the way we count case statements, going back to my original approach of not including the fall-through in the counter values. This was necessary because there isn't always an AST node that can be used to record the fall-through count. Now case statements are handled the same as default statements, with the fall-through paths branching over the counter increments. While I was at it, I also went back to using this approach for do-loops -- omitting the fall-through count into the loop body simplifies some of the calculations and make them behave the same as other loops. Whenever we start using this instrumentation for coverage, we'll need to add the fall-through counts into the counter values. llvm-svn: 201528
2014-02-18 03:21:09 +08:00
PGO.setCurrentStmt(E);
Abstract out everything having to do with member pointers into the ABI class; they should just be completely opaque throughout IR gen now, although I haven't really audited that. Fix a bug apparently inherited from gcc-4.2 where we failed to null-check member data pointers when performing derived-to-base or base-to-derived conversions on them. llvm-svn: 111789
2010-08-23 09:21:21 +08:00
if (const MemberPointerType *MPT = E->getType()->getAs<MemberPointerType>()) {
Experiment with using first-class aggregates to represent member function pointers. I find the resulting code to be substantially cleaner, and it makes it very easy to use the same APIs for data member pointers (which I have conscientiously avoided here), and it avoids a plethora of potential inefficiencies due to excessive memory copying, but we'll have to see if it actually works. llvm-svn: 111776
2010-08-22 18:59:02 +08:00
llvm::Value *MemPtr = EmitScalarExpr(E);
Reorganize CodeGen{Function,Module} to eliminate the unfortunate Block{Function,Module} base class. Minor other refactorings. Fixed a few address-space bugs while I was there. llvm-svn: 125085
2011-02-08 16:22:06 +08:00
return CGM.getCXXABI().EmitMemberPointerIsNotNull(*this, MemPtr, MPT);
Move the code for converting a member pointer to a bool so that it is usable for logical not. llvm-svn: 91112
2009-12-11 17:26:29 +08:00
}
Abstract out everything having to do with member pointers into the ABI class; they should just be completely opaque throughout IR gen now, although I haven't really audited that. Fix a bug apparently inherited from gcc-4.2 where we failed to null-check member data pointers when performing derived-to-base or base-to-derived conversions on them. llvm-svn: 111789
2010-08-23 09:21:21 +08:00
QualType BoolTy = getContext().BoolTy;
Propagate SourceLocations through to get a Loc on float_cast_overflow Summary: float_cast_overflow is the only UBSan check without a source location attached. This patch propagates SourceLocations where necessary to get them to the EmitCheck() call. Reviewers: rsmith, ABataev, rjmccall Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11757 llvm-svn: 244568
2015-08-11 12:19:28 +08:00
SourceLocation Loc = E->getExprLoc();
Since isComplexType() no longer returns true for _Complex integers, the code generator needs to call isAnyComplexType(). This fixes PR1960. llvm-svn: 49220
2008-04-05 00:54:41 +08:00
if (!E->getType()->isAnyComplexType())
Propagate SourceLocations through to get a Loc on float_cast_overflow Summary: float_cast_overflow is the only UBSan check without a source location attached. This patch propagates SourceLocations where necessary to get them to the EmitCheck() call. Reviewers: rsmith, ABataev, rjmccall Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11757 llvm-svn: 244568
2015-08-11 12:19:28 +08:00
return EmitScalarConversion(EmitScalarExpr(E), E->getType(), BoolTy, Loc);
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
Propagate SourceLocations through to get a Loc on float_cast_overflow Summary: float_cast_overflow is the only UBSan check without a source location attached. This patch propagates SourceLocations where necessary to get them to the EmitCheck() call. Reviewers: rsmith, ABataev, rjmccall Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11757 llvm-svn: 244568
2015-08-11 12:19:28 +08:00
return EmitComplexToScalarConversion(EmitComplexExpr(E), E->getType(), BoolTy,
Loc);
Refactor EvaluateScalarValueToBool out of if statement emission, so it can be shared. Implement infrastructure for unary operator emission. Implement basic logical not support. We now compile: register short X; if (!X) { into: %tmp = load i16* %X ; <i16> [#uses=1] %tobool = icmp ne i16 %tmp, 0 ; <i1> [#uses=1] %lnot = xor i1 %tobool, true ; <i1> [#uses=1] zext i1 %lnot to i32 ; <i32>:0 [#uses=1] %tobool1 = icmp ne i32 %0, 0 ; <i1> [#uses=1] br i1 %tobool1, label %ifthen, label %ifend llvm-svn: 39559
2007-06-03 03:33:17 +08:00
}
Fix a bug in the emission of __real/__imag l-values on scalar operands. Fix a bug in the emission of complex compound assignment l-values. Introduce a method to emit an expression whose value isn't relevant. Make that method evaluate its operand as an l-value if it is one. Fixes our volatile compliance in C++. llvm-svn: 120931
2010-12-05 10:00:02 +08:00
/// EmitIgnoredExpr - Emit code to compute the specified expression,
/// ignoring the result.
void CodeGenFunction::EmitIgnoredExpr(const Expr *E) {
if (E->isRValue())
return (void) EmitAnyExpr(E, AggValueSlot::ignored(), true);
// Just emit it as an l-value and drop the result.
EmitLValue(E);
}
one piece of code is responsible for the lifetime of every aggregate slot. The easiest way to do that was to bundle up the information we care about for aggregate slots into a new structure which demands that its creators at least consider the question. I could probably be convinced that the ObjC 'needs GC' bit should be rolled into this structure. Implement generalized copy elision. The main obstacle here is that IR-generation must be much more careful about making sure that exactly llvm-svn: 113962
2010-09-15 18:14:12 +08:00
/// EmitAnyExpr - Emit code to compute the specified expression which
/// can have any type. The result is returned as an RValue struct.
/// If this is an aggregate expression, AggSlot indicates where the
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
/// result should be returned.
Significantly simplify CGExprAgg's logic about ignored results: if we want to ignore a result, the Dest will be null. Otherwise, we must copy into it. This means we need to ensure a slot when loading from a volatile l-value. With all that in place, fix a bug with chained assignments into __block variables of aggregate type where we were losing insight into the actual source of the value during the second assignment. llvm-svn: 159630
2012-07-03 07:58:38 +08:00
RValue CodeGenFunction::EmitAnyExpr(const Expr *E,
AggValueSlot aggSlot,
bool ignoreResult) {
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
switch (getEvaluationKind(E->getType())) {
case TEK_Scalar:
Significantly simplify CGExprAgg's logic about ignored results: if we want to ignore a result, the Dest will be null. Otherwise, we must copy into it. This means we need to ensure a slot when loading from a volatile l-value. With all that in place, fix a bug with chained assignments into __block variables of aggregate type where we were losing insight into the actual source of the value during the second assignment. llvm-svn: 159630
2012-07-03 07:58:38 +08:00
return RValue::get(EmitScalarExpr(E, ignoreResult));
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
case TEK_Complex:
Significantly simplify CGExprAgg's logic about ignored results: if we want to ignore a result, the Dest will be null. Otherwise, we must copy into it. This means we need to ensure a slot when loading from a volatile l-value. With all that in place, fix a bug with chained assignments into __block variables of aggregate type where we were losing insight into the actual source of the value during the second assignment. llvm-svn: 159630
2012-07-03 07:58:38 +08:00
return RValue::getComplex(EmitComplexExpr(E, ignoreResult, ignoreResult));
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
case TEK_Aggregate:
if (!ignoreResult && aggSlot.isIgnored())
aggSlot = CreateAggTemp(E->getType(), "agg-temp");
EmitAggExpr(E, aggSlot);
return aggSlot.asRValue();
}
llvm_unreachable("bad evaluation kind");
Generalize RValue to handle complex better, generalize EmitCompoundStmt to support any sort of expr, add a new EmitAnyExpr routine. llvm-svn: 41660
2007-09-01 06:49:20 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
/// EmitAnyExprToTemp - Similary to EmitAnyExpr(), however, the result will
/// always be accessible even if no aggregate location is provided.
one piece of code is responsible for the lifetime of every aggregate slot. The easiest way to do that was to bundle up the information we care about for aggregate slots into a new structure which demands that its creators at least consider the question. I could probably be convinced that the ObjC 'needs GC' bit should be rolled into this structure. Implement generalized copy elision. The main obstacle here is that IR-generation must be much more careful about making sure that exactly llvm-svn: 113962
2010-09-15 18:14:12 +08:00
RValue CodeGenFunction::EmitAnyExprToTemp(const Expr *E) {
AggValueSlot AggSlot = AggValueSlot::ignored();
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
if (hasAggregateEvaluationKind(E->getType()))
one piece of code is responsible for the lifetime of every aggregate slot. The easiest way to do that was to bundle up the information we care about for aggregate slots into a new structure which demands that its creators at least consider the question. I could probably be convinced that the ObjC 'needs GC' bit should be rolled into this structure. Implement generalized copy elision. The main obstacle here is that IR-generation must be much more careful about making sure that exactly llvm-svn: 113962
2010-09-15 18:14:12 +08:00
AggSlot = CreateAggTemp(E->getType(), "agg.tmp");
return EmitAnyExpr(E, AggSlot);
Change CodeGen to emit calls using (RValue,Type) list: - Add CodeGenFunction::EmitAnyExprToTemp o Like EmitAnyExpr, but emits aggregates to a temporary location if none is available. Seems like this should be simpler (even aside from using first class aggregates). - Killed CodeGenFunction::EmitCallArg (just append the pair) - Conversion of RValues to actual call arguments is now isolated in CodeGenFunction::EmitCall. llvm-svn: 55970
2008-09-09 09:06:48 +08:00
}
Miscellaneous codegen cleanups. Mostly, don't create new basic blocks just to save the current insertion state! This change significantly simplifies the IR CFG in exceptions code. llvm-svn: 101996
2010-04-21 18:05:39 +08:00
/// EmitAnyExprToMem - Evaluate an expression into a given memory
/// location.
void CodeGenFunction::EmitAnyExprToMem(const Expr *E,
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Location,
Revert r153613 as it's causing large compile-time regressions on the nightly testers. llvm-svn: 153660
2012-03-30 01:37:10 +08:00
Qualifiers Quals,
bool IsInit) {
Track alignment in AggValueSlot. No functional change in this patch, but I'll be introducing uses of the specified alignment soon. llvm-svn: 145736
2011-12-03 08:54:26 +08:00
// FIXME: This function should take an LValue as an argument.
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
switch (getEvaluationKind(E->getType())) {
case TEK_Complex:
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EmitComplexExprIntoLValue(E, MakeAddrLValue(Location, E->getType()),
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
/*isInit*/ false);
return;
case TEK_Aggregate: {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EmitAggExpr(E, AggValueSlot::forAddr(Location, Quals,
Revert r153613 as it's causing large compile-time regressions on the nightly testers. llvm-svn: 153660
2012-03-30 01:37:10 +08:00
AggValueSlot::IsDestructed_t(IsInit),
An initialization does not alias. llvm-svn: 138624
2011-08-26 13:38:08 +08:00
AggValueSlot::DoesNotNeedGCBarriers,
Revert r153613 as it's causing large compile-time regressions on the nightly testers. llvm-svn: 153660
2012-03-30 01:37:10 +08:00
AggValueSlot::IsAliased_t(!IsInit)));
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
return;
}
case TEK_Scalar: {
Miscellaneous codegen cleanups. Mostly, don't create new basic blocks just to save the current insertion state! This change significantly simplifies the IR CFG in exceptions code. llvm-svn: 101996
2010-04-21 18:05:39 +08:00
RValue RV = RValue::get(EmitScalarExpr(E, /*Ignore*/ false));
IRgen: Switch a bunch of trivial MakeAddr calls to use MakeAddrLValue. llvm-svn: 111716
2010-08-21 11:08:16 +08:00
LValue LV = MakeAddrLValue(Location, E->getType());
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
EmitStoreThroughLValue(RV, LV);
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
return;
Miscellaneous codegen cleanups. Mostly, don't create new basic blocks just to save the current insertion state! This change significantly simplifies the IR CFG in exceptions code. llvm-svn: 101996
2010-04-21 18:05:39 +08:00
}
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
}
llvm_unreachable("bad evaluation kind");
Miscellaneous codegen cleanups. Mostly, don't create new basic blocks just to save the current insertion state! This change significantly simplifies the IR CFG in exceptions code. llvm-svn: 101996
2010-04-21 18:05:39 +08:00
}
Revert r218865 because it introduced PR21236, a crash in codegen emitting the try block. llvm-svn: 219470
2014-10-10 12:05:00 +08:00
static void
pushTemporaryCleanup(CodeGenFunction &CGF, const MaterializeTemporaryExpr *M,
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
const Expr *E, Address ReferenceTemporary) {
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
// Objective-C++ ARC:
// If we are binding a reference to a temporary that has ownership, we
// need to perform retain/release operations on the temporary.
//
// FIXME: This should be looking at E, not M.
if (CGF.getLangOpts().ObjCAutoRefCount &&
M->getType()->isObjCLifetimeType()) {
QualType ObjCARCReferenceLifetimeType = M->getType();
switch (Qualifiers::ObjCLifetime Lifetime =
ObjCARCReferenceLifetimeType.getObjCLifetime()) {
case Qualifiers::OCL_None:
case Qualifiers::OCL_ExplicitNone:
// Carry on to normal cleanup handling.
break;
case Qualifiers::OCL_Autoreleasing:
// Nothing to do; cleaned up by an autorelease pool.
return;
case Qualifiers::OCL_Strong:
case Qualifiers::OCL_Weak:
switch (StorageDuration Duration = M->getStorageDuration()) {
case SD_Static:
// Note: we intentionally do not register a cleanup to release
// the object on program termination.
return;
case SD_Thread:
// FIXME: We should probably register a cleanup in this case.
return;
case SD_Automatic:
case SD_FullExpression:
CodeGenFunction::Destroyer *Destroy;
CleanupKind CleanupKind;
if (Lifetime == Qualifiers::OCL_Strong) {
const ValueDecl *VD = M->getExtendingDecl();
bool Precise =
VD && isa<VarDecl>(VD) && VD->hasAttr<ObjCPreciseLifetimeAttr>();
CleanupKind = CGF.getARCCleanupKind();
Destroy = Precise ? &CodeGenFunction::destroyARCStrongPrecise
: &CodeGenFunction::destroyARCStrongImprecise;
} else {
// __weak objects always get EH cleanups; otherwise, exceptions
// could cause really nasty crashes instead of mere leaks.
CleanupKind = NormalAndEHCleanup;
Destroy = &CodeGenFunction::destroyARCWeak;
}
if (Duration == SD_FullExpression)
CGF.pushDestroy(CleanupKind, ReferenceTemporary,
ObjCARCReferenceLifetimeType, *Destroy,
CleanupKind & EHCleanup);
else
CGF.pushLifetimeExtendedDestroy(CleanupKind, ReferenceTemporary,
ObjCARCReferenceLifetimeType,
*Destroy, CleanupKind & EHCleanup);
return;
case SD_Dynamic:
llvm_unreachable("temporary cannot have dynamic storage duration");
}
llvm_unreachable("unknown storage duration");
Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183721
2013-06-11 10:41:00 +08:00
}
}
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
CXXDestructorDecl *ReferenceTemporaryDtor = nullptr;
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
if (const RecordType *RT =
E->getType()->getBaseElementTypeUnsafe()->getAs<RecordType>()) {
// Get the destructor for the reference temporary.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *ClassDecl = cast<CXXRecordDecl>(RT->getDecl());
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
if (!ClassDecl->hasTrivialDestructor())
ReferenceTemporaryDtor = ClassDecl->getDestructor();
}
if (!ReferenceTemporaryDtor)
return;
// Call the destructor for the temporary.
switch (M->getStorageDuration()) {
case SD_Static:
case SD_Thread: {
llvm::Constant *CleanupFn;
llvm::Constant *CleanupArg;
if (E->getType()->isArrayType()) {
CleanupFn = CodeGenFunction(CGF.CGM).generateDestroyHelper(
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ReferenceTemporary, E->getType(),
Revert "PR14569: Omit debug info for thunks" This reverts commit r189320. Alexey Samsonov and Dmitry Vyukov presented some arguments for keeping these around - though it still seems like those tasks could be solved by a tool just using the symbol table. In a very small number of cases, thunks may be inlined & debug info might be able to save profilers & similar tools from misclassifying those cases as part of the caller. The extra changes here plumb through the VarDecl for various cases to CodeGenFunction - this provides better fidelity through a few APIs but generally just causes the CGF::StartFunction to fallback to using the name of the IR function as the name in the debug info. The changes to debug-info-global-ctor-dtor.cpp seem like goodness. The two names that go missing (in favor of only emitting those names as linkage names) are names that can be demangled - emitting them only as the linkage name should encourage tools to do just that. Again, thanks to Dinesh Dwivedi for investigation/work on this issue. llvm-svn: 189421
2013-08-28 07:57:18 +08:00
CodeGenFunction::destroyCXXObject, CGF.getLangOpts().Exceptions,
dyn_cast_or_null<VarDecl>(M->getExtendingDecl()));
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
CleanupArg = llvm::Constant::getNullValue(CGF.Int8PtrTy);
} else {
Merge GetAddrOfCXXConstructor and GetAddrOfCXXDonstructor. NFC. llvm-svn: 217598
2014-09-11 23:42:06 +08:00
CleanupFn = CGF.CGM.getAddrOfCXXStructor(ReferenceTemporaryDtor,
StructorType::Complete);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CleanupArg = cast<llvm::Constant>(ReferenceTemporary.getPointer());
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
}
CGF.CGM.getCXXABI().registerGlobalDtor(
CGF, *cast<VarDecl>(M->getExtendingDecl()), CleanupFn, CleanupArg);
break;
}
case SD_FullExpression:
CGF.pushDestroy(NormalAndEHCleanup, ReferenceTemporary, E->getType(),
CodeGenFunction::destroyCXXObject,
CGF.getLangOpts().Exceptions);
break;
case SD_Automatic:
CGF.pushLifetimeExtendedDestroy(NormalAndEHCleanup,
ReferenceTemporary, E->getType(),
CodeGenFunction::destroyCXXObject,
CGF.getLangOpts().Exceptions);
break;
case SD_Dynamic:
llvm_unreachable("temporary cannot have dynamic storage duration");
}
Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183721
2013-06-11 10:41:00 +08:00
}
Reference initialization with initializer lists. This supports single-element initializer lists for references according to DR1288, as well as creating temporaries and binding to them for other initializer lists. llvm-svn: 145186
2011-11-28 00:50:07 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
static Address
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
createReferenceTemporary(CodeGenFunction &CGF,
Revert r218865 because it introduced PR21236, a crash in codegen emitting the try block. llvm-svn: 219470
2014-10-10 12:05:00 +08:00
const MaterializeTemporaryExpr *M, const Expr *Inner) {
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
switch (M->getStorageDuration()) {
case SD_FullExpression:
[CodeGen] Do a more principled fix for PR231653, always use the inner type. We were still using the MaterializeTemporaryExpr's type to check if the transform is legal. Always use the inner Expr type. llvm-svn: 234543
2015-04-10 06:50:07 +08:00
case SD_Automatic: {
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
// If we have a constant temporary array or record try to promote it into a
// constant global under the same rules a normal constant would've been
// promoted. This is easier on the optimizer and generally emits fewer
// instructions.
[CodeGen] Do a more principled fix for PR231653, always use the inner type. We were still using the MaterializeTemporaryExpr's type to check if the transform is legal. Always use the inner Expr type. llvm-svn: 234543
2015-04-10 06:50:07 +08:00
QualType Ty = Inner->getType();
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
if (CGF.CGM.getCodeGenOpts().MergeAllConstants &&
[CodeGen] Do a more principled fix for PR231653, always use the inner type. We were still using the MaterializeTemporaryExpr's type to check if the transform is legal. Always use the inner Expr type. llvm-svn: 234543
2015-04-10 06:50:07 +08:00
(Ty->isArrayType() || Ty->isRecordType()) &&
CGF.CGM.isTypeConstant(Ty, true))
if (llvm::Constant *Init = CGF.CGM.EmitConstantExpr(Inner, Ty, &CGF)) {
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
auto *GV = new llvm::GlobalVariable(
CGF.CGM.getModule(), Init->getType(), /*isConstant=*/true,
llvm::GlobalValue::PrivateLinkage, Init, ".ref.tmp");
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits alignment = CGF.getContext().getTypeAlignInChars(Ty);
GV->setAlignment(alignment.getQuantity());
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
// FIXME: Should we put the new global into a COMDAT?
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return Address(GV, alignment);
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
}
[CodeGen] Do a more principled fix for PR231653, always use the inner type. We were still using the MaterializeTemporaryExpr's type to check if the transform is legal. Always use the inner Expr type. llvm-svn: 234543
2015-04-10 06:50:07 +08:00
return CGF.CreateMemTemp(Ty, "ref.tmp");
}
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
case SD_Thread:
case SD_Static:
Revert r232454 and r232456: "Fix the LLVM type used when lowering initializer list reference temporaries to global variables." This caused PR22940. llvm-svn: 232496
2015-03-18 00:38:58 +08:00
return CGF.CGM.GetAddrOfGlobalTemporary(M, Inner);
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
case SD_Dynamic:
llvm_unreachable("temporary can't have dynamic storage duration");
}
llvm_unreachable("unknown storage duration");
}
Revert r183721. It caused cleanups to be delayed too long in some cases. Testcase to follow. llvm-svn: 183776
2013-06-12 03:14:25 +08:00
CodeGen: trivial conversion to range based loop Switch to a range-based for loop. NFC. llvm-svn: 220587
2014-10-25 03:54:32 +08:00
LValue CodeGenFunction::
EmitMaterializeTemporaryExpr(const MaterializeTemporaryExpr *M) {
Simplify: we don't need any special-case lifetime extension when initializing declarations of reference type; they're handled by the general case handling of MaterializeTemporaryExpr. llvm-svn: 183875
2013-06-13 07:38:09 +08:00
const Expr *E = M->GetTemporaryExpr();
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
CodeGen: correct materialize temporary aggregates in ARC mode Avoid an assertion when materializing a lifetime type aggregate temporary. When performing CodeGen for ObjC++, we could generate a lifetime-only aggregate temporary by using an initializer list (which is effectively an array). We would reach through the temporary expression, fishing out the inner expression. If this expression was a lifetime expression, we would attempt to emit this as a scalar. This would eventually result in an assertion as the emission would eventually assert that the expression being emitted has a scalar evaluation kind. Add a case to handle the aggregate expressions. Use the EmitAggExpr to emit the aggregate expression rather than the EmitScalarInit. Addresses PR21347. llvm-svn: 220590
2014-10-25 04:23:43 +08:00
// FIXME: ideally this would use EmitAnyExprToMem, however, we cannot do so
// as that will cause the lifetime adjustment to be lost for ARC
Simplify: we don't need any special-case lifetime extension when initializing declarations of reference type; they're handled by the general case handling of MaterializeTemporaryExpr. llvm-svn: 183875
2013-06-13 07:38:09 +08:00
if (getLangOpts().ObjCAutoRefCount &&
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
M->getType()->isObjCLifetimeType() &&
M->getType().getObjCLifetime() != Qualifiers::OCL_None &&
M->getType().getObjCLifetime() != Qualifiers::OCL_ExplicitNone) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Object = createReferenceTemporary(*this, M, E);
if (auto *Var = dyn_cast<llvm::GlobalVariable>(Object.getPointer())) {
Object = Address(llvm::ConstantExpr::getBitCast(Var,
ConvertTypeForMem(E->getType())
->getPointerTo(Object.getAddressSpace())),
Object.getAlignment());
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
// We should not have emitted the initializer for this temporary as a
// constant.
assert(!Var->hasInitializer());
Var->setInitializer(CGM.EmitNullConstant(E->getType()));
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue RefTempDst = MakeAddrLValue(Object, M->getType(),
AlignmentSource::Decl);
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
CodeGen: correct materialize temporary aggregates in ARC mode Avoid an assertion when materializing a lifetime type aggregate temporary. When performing CodeGen for ObjC++, we could generate a lifetime-only aggregate temporary by using an initializer list (which is effectively an array). We would reach through the temporary expression, fishing out the inner expression. If this expression was a lifetime expression, we would attempt to emit this as a scalar. This would eventually result in an assertion as the emission would eventually assert that the expression being emitted has a scalar evaluation kind. Add a case to handle the aggregate expressions. Use the EmitAggExpr to emit the aggregate expression rather than the EmitScalarInit. Addresses PR21347. llvm-svn: 220590
2014-10-25 04:23:43 +08:00
switch (getEvaluationKind(E->getType())) {
default: llvm_unreachable("expected scalar or aggregate expression");
case TEK_Scalar:
EmitScalarInit(E, M->getExtendingDecl(), RefTempDst, false);
break;
case TEK_Aggregate: {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EmitAggExpr(E, AggValueSlot::forAddr(Object,
CodeGen: correct materialize temporary aggregates in ARC mode Avoid an assertion when materializing a lifetime type aggregate temporary. When performing CodeGen for ObjC++, we could generate a lifetime-only aggregate temporary by using an initializer list (which is effectively an array). We would reach through the temporary expression, fishing out the inner expression. If this expression was a lifetime expression, we would attempt to emit this as a scalar. This would eventually result in an assertion as the emission would eventually assert that the expression being emitted has a scalar evaluation kind. Add a case to handle the aggregate expressions. Use the EmitAggExpr to emit the aggregate expression rather than the EmitScalarInit. Addresses PR21347. llvm-svn: 220590
2014-10-25 04:23:43 +08:00
E->getType().getQualifiers(),
AggValueSlot::IsDestructed,
AggValueSlot::DoesNotNeedGCBarriers,
AggValueSlot::IsNotAliased));
break;
}
}
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
Revert r218865 because it introduced PR21236, a crash in codegen emitting the try block. llvm-svn: 219470
2014-10-10 12:05:00 +08:00
pushTemporaryCleanup(*this, M, E, Object);
Simplify: we don't need any special-case lifetime extension when initializing declarations of reference type; they're handled by the general case handling of MaterializeTemporaryExpr. llvm-svn: 183875
2013-06-13 07:38:09 +08:00
return RefTempDst;
Force a load when creating a reference to a temporary copied from a bitfield. For this source: const int &ref = someStruct.bitfield; We used to generate this AST: DeclStmt [...] `-VarDecl [...] ref 'const int &' `-MaterializeTemporaryExpr [...] 'const int' lvalue `-ImplicitCastExpr [...] 'const int' lvalue <NoOp> `-MemberExpr [...] 'int' lvalue bitfield .bitfield [...] `-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X' Notice the lvalue inside the MaterializeTemporaryExpr, which is very confusing (and caused an assertion to fire in the analyzer - PR15694). We now generate this: DeclStmt [...] `-VarDecl [...] ref 'const int &' `-MaterializeTemporaryExpr [...] 'const int' lvalue `-ImplicitCastExpr [...] 'int' <LValueToRValue> `-MemberExpr [...] 'int' lvalue bitfield .bitfield [...] `-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X' Which makes a lot more sense. This allows us to remove code in both CodeGen and AST that hacked around this special case. The commit also makes Clang accept this (legal) C++11 code: int &&ref = std::move(someStruct).bitfield PR15694 / <rdar://problem/13600396> llvm-svn: 179250
2013-04-11 08:58:58 +08:00
}
Fix handling of pointers-to-members and comma expressions when lifetime-extending temporaries in reference bindings. llvm-svn: 183089
2013-06-03 08:17:11 +08:00
SmallVector<const Expr *, 2> CommaLHSs;
Force a load when creating a reference to a temporary copied from a bitfield. For this source: const int &ref = someStruct.bitfield; We used to generate this AST: DeclStmt [...] `-VarDecl [...] ref 'const int &' `-MaterializeTemporaryExpr [...] 'const int' lvalue `-ImplicitCastExpr [...] 'const int' lvalue <NoOp> `-MemberExpr [...] 'int' lvalue bitfield .bitfield [...] `-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X' Notice the lvalue inside the MaterializeTemporaryExpr, which is very confusing (and caused an assertion to fire in the analyzer - PR15694). We now generate this: DeclStmt [...] `-VarDecl [...] ref 'const int &' `-MaterializeTemporaryExpr [...] 'const int' lvalue `-ImplicitCastExpr [...] 'int' <LValueToRValue> `-MemberExpr [...] 'int' lvalue bitfield .bitfield [...] `-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X' Which makes a lot more sense. This allows us to remove code in both CodeGen and AST that hacked around this special case. The commit also makes Clang accept this (legal) C++11 code: int &&ref = std::move(someStruct).bitfield PR15694 / <rdar://problem/13600396> llvm-svn: 179250
2013-04-11 08:58:58 +08:00
SmallVector<SubobjectAdjustment, 2> Adjustments;
Fix handling of pointers-to-members and comma expressions when lifetime-extending temporaries in reference bindings. llvm-svn: 183089
2013-06-03 08:17:11 +08:00
E = E->skipRValueSubobjectAdjustments(CommaLHSs, Adjustments);
CodeGen: trivial conversion to range based loop Switch to a range-based for loop. NFC. llvm-svn: 220587
2014-10-25 03:54:32 +08:00
for (const auto &Ignored : CommaLHSs)
EmitIgnoredExpr(Ignored);
Fix handling of pointers-to-members and comma expressions when lifetime-extending temporaries in reference bindings. llvm-svn: 183089
2013-06-03 08:17:11 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *opaque = dyn_cast<OpaqueValueExpr>(E)) {
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
if (opaque->getType()->isRecordType()) {
assert(Adjustments.empty());
Simplify: we don't need any special-case lifetime extension when initializing declarations of reference type; they're handled by the general case handling of MaterializeTemporaryExpr. llvm-svn: 183875
2013-06-13 07:38:09 +08:00
return EmitOpaqueValueLValue(opaque);
Force a load when creating a reference to a temporary copied from a bitfield. For this source: const int &ref = someStruct.bitfield; We used to generate this AST: DeclStmt [...] `-VarDecl [...] ref 'const int &' `-MaterializeTemporaryExpr [...] 'const int' lvalue `-ImplicitCastExpr [...] 'const int' lvalue <NoOp> `-MemberExpr [...] 'int' lvalue bitfield .bitfield [...] `-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X' Notice the lvalue inside the MaterializeTemporaryExpr, which is very confusing (and caused an assertion to fire in the analyzer - PR15694). We now generate this: DeclStmt [...] `-VarDecl [...] ref 'const int &' `-MaterializeTemporaryExpr [...] 'const int' lvalue `-ImplicitCastExpr [...] 'int' <LValueToRValue> `-MemberExpr [...] 'int' lvalue bitfield .bitfield [...] `-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X' Which makes a lot more sense. This allows us to remove code in both CodeGen and AST that hacked around this special case. The commit also makes Clang accept this (legal) C++11 code: int &&ref = std::move(someStruct).bitfield PR15694 / <rdar://problem/13600396> llvm-svn: 179250
2013-04-11 08:58:58 +08:00
}
}
Simplify CodeGenFunction::EmitReferenceBindingToExpr as a first step towards fixing PR7326. llvm-svn: 106981
2010-06-28 00:56:04 +08:00
Revert r218865 because it introduced PR21236, a crash in codegen emitting the try block. llvm-svn: 219470
2014-10-10 12:05:00 +08:00
// Create and initialize the reference temporary.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Object = createReferenceTemporary(*this, M, E);
if (auto *Var = dyn_cast<llvm::GlobalVariable>(Object.getPointer())) {
Object = Address(llvm::ConstantExpr::getBitCast(
Var, ConvertTypeForMem(E->getType())->getPointerTo()),
Object.getAlignment());
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals." I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time. I hope the chromium build doesn't break this time :) llvm-svn: 231564
2015-03-07 21:37:13 +08:00
// If the temporary is a global and has a constant initializer or is a
// constant temporary that we promoted to a global, we may have already
// initialized it.
Emit initializers for static-storage-duration temporaries as constants where possible. llvm-svn: 183967
2013-06-14 11:07:01 +08:00
if (!Var->hasInitializer()) {
Var->setInitializer(CGM.EmitNullConstant(E->getType()));
EmitAnyExprToMem(E, Object, Qualifiers(), /*IsInit*/true);
}
} else {
EmitAnyExprToMem(E, Object, Qualifiers(), /*IsInit*/true);
}
Revert r218865 because it introduced PR21236, a crash in codegen emitting the try block. llvm-svn: 219470
2014-10-10 12:05:00 +08:00
pushTemporaryCleanup(*this, M, E, Object);
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
// Perform derived-to-base casts and/or field accesses, to get from the
// temporary object we created (and, potentially, for which we extended
// the lifetime) to the subobject we're binding the reference to.
for (unsigned I = Adjustments.size(); I != 0; --I) {
SubobjectAdjustment &Adjustment = Adjustments[I-1];
switch (Adjustment.Kind) {
case SubobjectAdjustment::DerivedToBaseAdjustment:
Object =
Simplify: we don't need any special-case lifetime extension when initializing declarations of reference type; they're handled by the general case handling of MaterializeTemporaryExpr. llvm-svn: 183875
2013-06-13 07:38:09 +08:00
GetAddressOfBaseClass(Object, Adjustment.DerivedToBase.DerivedClass,
Adjustment.DerivedToBase.BasePath->path_begin(),
Adjustment.DerivedToBase.BasePath->path_end(),
Sanitize upcasts and conversion to virtual base. This change adds UBSan check to upcasts. Namely, when we perform derived-to-base conversion, we: 1) check that the pointer-to-derived has suitable alignment and underlying storage, if this pointer is non-null. 2) if vptr-sanitizer is enabled, and we perform conversion to virtual base, we check that pointer-to-derived has a matching vptr. llvm-svn: 219642
2014-10-14 07:59:00 +08:00
/*NullCheckValue=*/ false, E->getExprLoc());
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
break;
PR9494: Get rid of bitcast which was both unnecessary and written incorrectly. llvm-svn: 127768
2011-03-17 06:34:09 +08:00
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
case SubobjectAdjustment::FieldAdjustment: {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue LV = MakeAddrLValue(Object, E->getType(),
AlignmentSource::Decl);
Simplify: we don't need any special-case lifetime extension when initializing declarations of reference type; they're handled by the general case handling of MaterializeTemporaryExpr. llvm-svn: 183875
2013-06-13 07:38:09 +08:00
LV = EmitLValueForField(LV, Adjustment.Field);
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
assert(LV.isSimple() &&
"materialized temporary field is not a simple lvalue");
Object = LV.getAddress();
break;
Handle struct A { }; struct B : A { }; void f() { const A& a = B(); } correctly. (This now does the offset conversion if necessary and calls the destructor when a goes out of scope). llvm-svn: 84162
2009-10-15 08:51:46 +08:00
}
Force a load when creating a reference to a temporary copied from a bitfield. For this source: const int &ref = someStruct.bitfield; We used to generate this AST: DeclStmt [...] `-VarDecl [...] ref 'const int &' `-MaterializeTemporaryExpr [...] 'const int' lvalue `-ImplicitCastExpr [...] 'const int' lvalue <NoOp> `-MemberExpr [...] 'int' lvalue bitfield .bitfield [...] `-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X' Notice the lvalue inside the MaterializeTemporaryExpr, which is very confusing (and caused an assertion to fire in the analyzer - PR15694). We now generate this: DeclStmt [...] `-VarDecl [...] ref 'const int &' `-MaterializeTemporaryExpr [...] 'const int' lvalue `-ImplicitCastExpr [...] 'int' <LValueToRValue> `-MemberExpr [...] 'int' lvalue bitfield .bitfield [...] `-DeclRefExpr [...] 'struct X' lvalue ParmVar [...] 'someStruct' 'struct X' Which makes a lot more sense. This allows us to remove code in both CodeGen and AST that hacked around this special case. The commit also makes Clang accept this (legal) C++11 code: int &&ref = std::move(someStruct).bitfield PR15694 / <rdar://problem/13600396> llvm-svn: 179250
2013-04-11 08:58:58 +08:00
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
case SubobjectAdjustment::MemberPointerAdjustment: {
Simplify: we don't need any special-case lifetime extension when initializing declarations of reference type; they're handled by the general case handling of MaterializeTemporaryExpr. llvm-svn: 183875
2013-06-13 07:38:09 +08:00
llvm::Value *Ptr = EmitScalarExpr(Adjustment.Ptr.RHS);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Object = EmitCXXMemberDataPointerAddress(E, Object, Ptr,
Adjustment.Ptr.MPT);
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
break;
}
}
Bind references to lvalues correctly. llvm-svn: 72150
2009-05-20 08:36:58 +08:00
}
Handle the remaining unhandled cases in EmitReferenceBindingToExpr. It would be nice if someone could write an ObjC++ testcase for the case of passing a property returning a struct to a function taking a const reference. llvm-svn: 72159
2009-05-20 10:31:19 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(Object, M->getType(), AlignmentSource::Decl);
Simplify CodeGenFunction::EmitReferenceBindingToExpr as a first step towards fixing PR7326. llvm-svn: 106981
2010-06-28 00:56:04 +08:00
}
RValue
Simplify: we don't need any special-case lifetime extension when initializing declarations of reference type; they're handled by the general case handling of MaterializeTemporaryExpr. llvm-svn: 183875
2013-06-13 07:38:09 +08:00
CodeGenFunction::EmitReferenceBindingToExpr(const Expr *E) {
// Emit the expression as an lvalue.
LValue LV = EmitLValue(E);
assert(LV.isSimple());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *Value = LV.getPointer();
Reapply r183721, reverted in r183776, with a fix for a bug in the former (we were lacking ExprWithCleanups nodes in some cases where the new approach to lifetime extension needed them). Original commit message: Rework IR emission for lifetime-extended temporaries. Instead of trying to walk into the expression and dig out a single lifetime-extended entity and manually pull its cleanup outside the expression, instead keep a list of the cleanups which we'll need to emit when we get to the end of the full-expression. Also emit those cleanups early, as EH-only cleanups, to cover the case that the full-expression does not terminate normally. This allows IR generation to properly model temporary lifetime when multiple temporaries are extended by the same declaration. We have a pre-existing bug where an exception thrown from a temporary's destructor does not clean up lifetime-extended temporaries created in the same expression and extended to automatic storage duration; that is not fixed by this patch. llvm-svn: 183859
2013-06-13 04:42:33 +08:00
[Sanitizer] Remove brittle cache variable and slightly simplify blacklisting code. Now CodeGenFunction is responsible for looking at sanitizer blacklist (in CodeGenFunction::StartFunction) and turning off instrumentation, if necessary. No functionality change. llvm-svn: 212501
2014-07-08 07:59:57 +08:00
if (sanitizePerformTypeCheck() && !E->getType()->isFunctionType()) {
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
// C++11 [dcl.ref]p5 (as amended by core issue 453):
// If a glvalue to which a reference is directly bound designates neither
// an existing object or function of an appropriate type nor a region of
// storage of suitable size and alignment to contain an object of the
// reference's type, the behavior is undefined.
QualType Ty = E->getType();
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
EmitTypeCheck(TCK_ReferenceBinding, E->getExprLoc(), Value, Ty);
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
}
Switch the destructor for a temporary arising from a reference binding over to using a lazy cleanup. llvm-svn: 108994
2010-07-21 14:29:51 +08:00
Simplify CodeGenFunction::EmitReferenceBindingToExpr as a first step towards fixing PR7326. llvm-svn: 106981
2010-06-28 00:56:04 +08:00
return RValue::get(Value);
Add EmitReferenceBindingToExpr. Have EmitCallArg use it for now. Doesn't support anything but at least we don't crash ;) llvm-svn: 72147
2009-05-20 08:24:07 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
/// getAccessedFieldNo - Given an encoded value and a result number, return the
/// input field number being accessed.
unsigned CodeGenFunction::getAccessedFieldNo(unsigned Idx,
Move getAccessedFieldNo out of lib/AST/Expr.cpp into lib/CodeGen/CGExpr.cpp and to change include/clang/AST/Attr.h to use its own enum for visibility types instead of using llvm::GlobalValue::VisibilityTypes. These changes eliminate dependencies in the AST library on LLVM's VMCore library. llvm-svn: 51398
2008-05-22 08:50:06 +08:00
const llvm::Constant *Elts) {
Simplify code by using the new getAggregateElement method that got added recently. This also conveniently gets clang ready for a change about to land in mainline. llvm-svn: 149225
2012-01-30 14:20:36 +08:00
return cast<llvm::ConstantInt>(Elts->getAggregateElement(Idx))
->getZExtValue();
Move getAccessedFieldNo out of lib/AST/Expr.cpp into lib/CodeGen/CGExpr.cpp and to change include/clang/AST/Attr.h to use its own enum for visibility types instead of using llvm::GlobalValue::VisibilityTypes. These changes eliminate dependencies in the AST library on LLVM's VMCore library. llvm-svn: 51398
2008-05-22 08:50:06 +08:00
}
-fcatch-undefined-behavior checking for appropriate vptr value: Clang CodeGen side. llvm-svn: 166661
2012-10-25 10:14:12 +08:00
/// Emit the hash_16_bytes function from include/llvm/ADT/Hashing.h.
static llvm::Value *emitHash16Bytes(CGBuilderTy &Builder, llvm::Value *Low,
llvm::Value *High) {
llvm::Value *KMul = Builder.getInt64(0x9ddfea08eb382d69ULL);
llvm::Value *K47 = Builder.getInt64(47);
llvm::Value *A0 = Builder.CreateMul(Builder.CreateXor(Low, High), KMul);
llvm::Value *A1 = Builder.CreateXor(Builder.CreateLShr(A0, K47), A0);
llvm::Value *B0 = Builder.CreateMul(Builder.CreateXor(High, A1), KMul);
llvm::Value *B1 = Builder.CreateXor(Builder.CreateLShr(B0, K47), B0);
return Builder.CreateMul(B1, KMul);
}
[Sanitizer] Remove brittle cache variable and slightly simplify blacklisting code. Now CodeGenFunction is responsible for looking at sanitizer blacklist (in CodeGenFunction::StartFunction) and turning off instrumentation, if necessary. No functionality change. llvm-svn: 212501
2014-07-08 07:59:57 +08:00
bool CodeGenFunction::sanitizePerformTypeCheck() const {
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
return SanOpts.has(SanitizerKind::Null) |
SanOpts.has(SanitizerKind::Alignment) |
SanOpts.has(SanitizerKind::ObjectSize) |
SanOpts.has(SanitizerKind::Vptr);
[Sanitizer] Remove brittle cache variable and slightly simplify blacklisting code. Now CodeGenFunction is responsible for looking at sanitizer blacklist (in CodeGenFunction::StartFunction) and turning off instrumentation, if necessary. No functionality change. llvm-svn: 212501
2014-07-08 07:59:57 +08:00
}
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
void CodeGenFunction::EmitTypeCheck(TypeCheckKind TCK, SourceLocation Loc,
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *Ptr, QualType Ty,
Sanitize upcasts and conversion to virtual base. This change adds UBSan check to upcasts. Namely, when we perform derived-to-base conversion, we: 1) check that the pointer-to-derived has suitable alignment and underlying storage, if this pointer is non-null. 2) if vptr-sanitizer is enabled, and we perform conversion to virtual base, we check that pointer-to-derived has a matching vptr. llvm-svn: 219642
2014-10-14 07:59:00 +08:00
CharUnits Alignment, bool SkipNullCheck) {
[Sanitizer] Remove brittle cache variable and slightly simplify blacklisting code. Now CodeGenFunction is responsible for looking at sanitizer blacklist (in CodeGenFunction::StartFunction) and turning off instrumentation, if necessary. No functionality change. llvm-svn: 212501
2014-07-08 07:59:57 +08:00
if (!sanitizePerformTypeCheck())
Implement additional undefined checks for additional loads and stores. WIP. llvm-svn: 91498
2009-12-16 10:57:00 +08:00
return;
-fcatch-undefined-behavior: Start checking loads and stores for null pointers. We want the diagnostic, and if the load is optimized away, we still want to trap it. Stop checking non-default address spaces; that doesn't work in general. llvm-svn: 167219
2012-11-01 15:22:08 +08:00
// Don't check pointers outside the default address space. The null check
// isn't correct, the object-size check isn't supported by LLVM, and we can't
// communicate the addresses to the runtime handler for the vptr check.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
if (Ptr->getType()->getPointerAddressSpace())
-fcatch-undefined-behavior: Start checking loads and stores for null pointers. We want the diagnostic, and if the load is optimized away, we still want to trap it. Stop checking non-default address spaces; that doesn't work in general. llvm-svn: 167219
2012-11-01 15:22:08 +08:00
return;
[UBSan] Add !nosanitize metadata to the code generated by UBSan. This is used to mark the instructions emitted by Clang to implement variety of UBSan checks. Generally, we don't want to instrument these instructions with another sanitizers (like ASan). Reviewed in http://reviews.llvm.org/D4544 llvm-svn: 213291
2014-07-18 02:46:27 +08:00
SanitizerScope SanScope(this);
Unify sanitizer kind representation between the driver and the rest of the compiler. No functional change. Differential Revision: http://reviews.llvm.org/D9618 llvm-svn: 237055
2015-05-12 05:39:14 +08:00
SmallVector<std::pair<llvm::Value *, SanitizerMask>, 3> Checks;
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::BasicBlock *Done = nullptr;
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
Sanitize upcasts and conversion to virtual base. This change adds UBSan check to upcasts. Namely, when we perform derived-to-base conversion, we: 1) check that the pointer-to-derived has suitable alignment and underlying storage, if this pointer is non-null. 2) if vptr-sanitizer is enabled, and we perform conversion to virtual base, we check that pointer-to-derived has a matching vptr. llvm-svn: 219642
2014-10-14 07:59:00 +08:00
bool AllowNullPointers = TCK == TCK_DowncastPointer || TCK == TCK_Upcast ||
TCK == TCK_UpcastToVirtualBase;
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
if ((SanOpts.has(SanitizerKind::Null) || AllowNullPointers) &&
!SkipNullCheck) {
Use the individual -fsanitize=<...> arguments to control which of the UBSan checks to enable. Remove frontend support for -fcatch-undefined-behavior, -faddress-sanitizer and -fthread-sanitizer now that they don't do anything. llvm-svn: 167413
2012-11-06 06:21:05 +08:00
// The glvalue must not be an empty glvalue.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *IsNonNull = Builder.CreateIsNotNull(Ptr);
ubsan: Add checking for invalid downcasts. Per [expr.static.cast]p2 and p11, base-to-derived casts have undefined behavior if the object is not actually an instance of the derived type. llvm-svn: 175078
2013-02-14 05:18:23 +08:00
Sanitize upcasts and conversion to virtual base. This change adds UBSan check to upcasts. Namely, when we perform derived-to-base conversion, we: 1) check that the pointer-to-derived has suitable alignment and underlying storage, if this pointer is non-null. 2) if vptr-sanitizer is enabled, and we perform conversion to virtual base, we check that pointer-to-derived has a matching vptr. llvm-svn: 219642
2014-10-14 07:59:00 +08:00
if (AllowNullPointers) {
// When performing pointer casts, it's OK if the value is null.
ubsan: Add checking for invalid downcasts. Per [expr.static.cast]p2 and p11, base-to-derived casts have undefined behavior if the object is not actually an instance of the derived type. llvm-svn: 175078
2013-02-14 05:18:23 +08:00
// Skip the remaining checks in that case.
Done = createBasicBlock("null");
llvm::BasicBlock *Rest = createBasicBlock("not.null");
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
Builder.CreateCondBr(IsNonNull, Rest, Done);
ubsan: Add checking for invalid downcasts. Per [expr.static.cast]p2 and p11, base-to-derived casts have undefined behavior if the object is not actually an instance of the derived type. llvm-svn: 175078
2013-02-14 05:18:23 +08:00
EmitBlock(Rest);
Propagate SanitizerKind into CodeGenFunction::EmitCheck() call. Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
2014-11-11 06:27:30 +08:00
} else {
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
Checks.push_back(std::make_pair(IsNonNull, SanitizerKind::Null));
ubsan: Add checking for invalid downcasts. Per [expr.static.cast]p2 and p11, base-to-derived casts have undefined behavior if the object is not actually an instance of the derived type. llvm-svn: 175078
2013-02-14 05:18:23 +08:00
}
Use the individual -fsanitize=<...> arguments to control which of the UBSan checks to enable. Remove frontend support for -fcatch-undefined-behavior, -faddress-sanitizer and -fthread-sanitizer now that they don't do anything. llvm-svn: 167413
2012-11-06 06:21:05 +08:00
}
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
if (SanOpts.has(SanitizerKind::ObjectSize) && !Ty->isIncompleteType()) {
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
uint64_t Size = getContext().getTypeSizeInChars(Ty).getQuantity();
// The glvalue must refer to a large enough storage region.
Use the individual -fsanitize=<...> arguments to control which of the UBSan checks to enable. Remove frontend support for -fcatch-undefined-behavior, -faddress-sanitizer and -fthread-sanitizer now that they don't do anything. llvm-svn: 167413
2012-11-06 06:21:05 +08:00
// FIXME: If Address Sanitizer is enabled, insert dynamic instrumentation
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
// to check this.
Fix objectsize tests after r192117 llvm-svn: 192120
2013-10-08 03:00:18 +08:00
// FIXME: Get object address space
llvm::Type *Tys[2] = { IntPtrTy, Int8PtrTy };
llvm::Value *F = CGM.getIntrinsic(llvm::Intrinsic::objectsize, Tys);
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
llvm::Value *Min = Builder.getFalse();
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *CastAddr = Builder.CreateBitCast(Ptr, Int8PtrTy);
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
llvm::Value *LargeEnough =
API update for streamlining of IRBuilder::CreateCall to just use ArrayRef/initializer_list+braced init llvm-svn: 237625
2015-05-19 06:14:03 +08:00
Builder.CreateICmpUGE(Builder.CreateCall(F, {CastAddr, Min}),
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
llvm::ConstantInt::get(IntPtrTy, Size));
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
Checks.push_back(std::make_pair(LargeEnough, SanitizerKind::ObjectSize));
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
}
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
Use the individual -fsanitize=<...> arguments to control which of the UBSan checks to enable. Remove frontend support for -fcatch-undefined-behavior, -faddress-sanitizer and -fthread-sanitizer now that they don't do anything. llvm-svn: 167413
2012-11-06 06:21:05 +08:00
uint64_t AlignVal = 0;
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
if (SanOpts.has(SanitizerKind::Alignment)) {
Use the individual -fsanitize=<...> arguments to control which of the UBSan checks to enable. Remove frontend support for -fcatch-undefined-behavior, -faddress-sanitizer and -fthread-sanitizer now that they don't do anything. llvm-svn: 167413
2012-11-06 06:21:05 +08:00
AlignVal = Alignment.getQuantity();
if (!Ty->isIncompleteType() && !AlignVal)
AlignVal = getContext().getTypeAlignInChars(Ty).getQuantity();
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
// The glvalue must be suitably aligned.
Use the individual -fsanitize=<...> arguments to control which of the UBSan checks to enable. Remove frontend support for -fcatch-undefined-behavior, -faddress-sanitizer and -fthread-sanitizer now that they don't do anything. llvm-svn: 167413
2012-11-06 06:21:05 +08:00
if (AlignVal) {
llvm::Value *Align =
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Builder.CreateAnd(Builder.CreatePtrToInt(Ptr, IntPtrTy),
Use the individual -fsanitize=<...> arguments to control which of the UBSan checks to enable. Remove frontend support for -fcatch-undefined-behavior, -faddress-sanitizer and -fthread-sanitizer now that they don't do anything. llvm-svn: 167413
2012-11-06 06:21:05 +08:00
llvm::ConstantInt::get(IntPtrTy, AlignVal - 1));
llvm::Value *Aligned =
Builder.CreateICmpEQ(Align, llvm::ConstantInt::get(IntPtrTy, 0));
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
Checks.push_back(std::make_pair(Aligned, SanitizerKind::Alignment));
Use the individual -fsanitize=<...> arguments to control which of the UBSan checks to enable. Remove frontend support for -fcatch-undefined-behavior, -faddress-sanitizer and -fthread-sanitizer now that they don't do anything. llvm-svn: 167413
2012-11-06 06:21:05 +08:00
}
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
}
fix PR6805: llvm.objectsize changed to take an i1 instead of an i32. llvm-svn: 100938
2010-04-11 02:34:14 +08:00
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
if (Checks.size() > 0) {
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
llvm::Constant *StaticData[] = {
EmitCheckSourceLocation(Loc),
EmitCheckTypeDescriptor(Ty),
llvm::ConstantInt::get(SizeTy, AlignVal),
llvm::ConstantInt::get(Int8Ty, TCK)
};
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EmitCheck(Checks, "type_mismatch", StaticData, Ptr);
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
}
-fcatch-undefined-behavior checking for appropriate vptr value: Clang CodeGen side. llvm-svn: 166661
2012-10-25 10:14:12 +08:00
Use the individual -fsanitize=<...> arguments to control which of the UBSan checks to enable. Remove frontend support for -fcatch-undefined-behavior, -faddress-sanitizer and -fthread-sanitizer now that they don't do anything. llvm-svn: 167413
2012-11-06 06:21:05 +08:00
// If possible, check that the vptr indicates that there is a subobject of
// type Ty at offset zero within this object.
Rein ubsan's vptr sanitizer back a bit. Per core issue 453, binding a reference to an object outside its lifetime does not have undefined behavior. llvm-svn: 170387
2012-12-18 08:22:45 +08:00
//
// C++11 [basic.life]p5,6:
// [For storage which does not refer to an object within its lifetime]
// The program has undefined behavior if:
// -- the [pointer or glvalue] is used to access a non-static data member
Fix typo (thanks to Jordan for spotting it!). llvm-svn: 170403
2012-12-18 11:04:38 +08:00
// or call a non-static member function
-fcatch-undefined-behavior checking for appropriate vptr value: Clang CodeGen side. llvm-svn: 166661
2012-10-25 10:14:12 +08:00
CXXRecordDecl *RD = Ty->getAsCXXRecordDecl();
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
if (SanOpts.has(SanitizerKind::Vptr) &&
ubsan: Add checking for invalid downcasts. Per [expr.static.cast]p2 and p11, base-to-derived casts have undefined behavior if the object is not actually an instance of the derived type. llvm-svn: 175078
2013-02-14 05:18:23 +08:00
(TCK == TCK_MemberAccess || TCK == TCK_MemberCall ||
Sanitize upcasts and conversion to virtual base. This change adds UBSan check to upcasts. Namely, when we perform derived-to-base conversion, we: 1) check that the pointer-to-derived has suitable alignment and underlying storage, if this pointer is non-null. 2) if vptr-sanitizer is enabled, and we perform conversion to virtual base, we check that pointer-to-derived has a matching vptr. llvm-svn: 219642
2014-10-14 07:59:00 +08:00
TCK == TCK_DowncastPointer || TCK == TCK_DowncastReference ||
TCK == TCK_UpcastToVirtualBase) &&
-fcatch-undefined-behavior checking for appropriate vptr value: Clang CodeGen side. llvm-svn: 166661
2012-10-25 10:14:12 +08:00
RD && RD->hasDefinition() && RD->isDynamicClass()) {
// Compute a hash of the mangled name of the type.
//
// FIXME: This is not guaranteed to be deterministic! Move to a
// fingerprinting mechanism once LLVM provides one. For the time
// being the implementation happens to be deterministic.
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallString<64> MangledName;
-fcatch-undefined-behavior checking for appropriate vptr value: Clang CodeGen side. llvm-svn: 166661
2012-10-25 10:14:12 +08:00
llvm::raw_svector_ostream Out(MangledName);
CGM.getCXXABI().getMangleContext().mangleCXXRTTI(Ty.getUnqualifiedType(),
Out);
[UBSan] Introduce type-based blacklisting. Teach UBSan vptr checker to ignore technically invalud down-casts on blacklisted types. Based on http://reviews.llvm.org/D4407 by Byoungyoung Lee! llvm-svn: 212770
2014-07-11 06:34:19 +08:00
// Blacklist based on the mangled type.
SanitizerBlacklist: blacklist functions by their source location. This commit changes the way we blacklist functions in ASan, TSan, MSan and UBSan. We used to treat function as "blacklisted" and turned off instrumentation in it in two cases: 1) Function is explicitly blacklisted by its mangled name. This part is not changed. 2) Function is located in llvm::Module, whose identifier is contained in the list of blacklisted sources. This is completely wrong, as llvm::Module may not correspond to the actual source file function is defined in. Also, function can be defined in a header, in which case user had to blacklist the .cpp file this header was #include'd into, not the header itself. Such functions could cause other problems - for instance, if the header was included in multiple source files, compiled separately and linked into a single executable, we could end up with both instrumented and non-instrumented version of the same function participating in the same link. After this change we will make blacklisting decision based on the SourceLocation of a function definition. If a function is not explicitly defined in the source file, (for example, the function is compiler-generated and responsible for initialization/destruction of a global variable), then it will be blacklisted if the corresponding global variable is defined in blacklisted source file, and will be instrumented otherwise. After this commit, the active users of blacklist files may have to revisit them. This is a backwards-incompatible change, but I don't think it's possible or makes sense to support the old incorrect behavior. I plan to make similar change for blacklisting GlobalVariables (which is ASan-specific). llvm-svn: 219997
2014-10-17 08:20:19 +08:00
if (!CGM.getContext().getSanitizerBlacklist().isBlacklistedType(
Out.str())) {
[UBSan] Introduce type-based blacklisting. Teach UBSan vptr checker to ignore technically invalud down-casts on blacklisted types. Based on http://reviews.llvm.org/D4407 by Byoungyoung Lee! llvm-svn: 212770
2014-07-11 06:34:19 +08:00
llvm::hash_code TypeHash = hash_value(Out.str());
// Load the vptr, and compute hash_16_bytes(TypeHash, vptr).
llvm::Value *Low = llvm::ConstantInt::get(Int64Ty, TypeHash);
llvm::Type *VPtrTy = llvm::PointerType::get(IntPtrTy, 0);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address VPtrAddr(Builder.CreateBitCast(Ptr, VPtrTy), getPointerAlign());
[UBSan] Introduce type-based blacklisting. Teach UBSan vptr checker to ignore technically invalud down-casts on blacklisted types. Based on http://reviews.llvm.org/D4407 by Byoungyoung Lee! llvm-svn: 212770
2014-07-11 06:34:19 +08:00
llvm::Value *VPtrVal = Builder.CreateLoad(VPtrAddr);
llvm::Value *High = Builder.CreateZExt(VPtrVal, Int64Ty);
llvm::Value *Hash = emitHash16Bytes(Builder, Low, High);
Hash = Builder.CreateTrunc(Hash, IntPtrTy);
// Look the hash up in our cache.
const int CacheSize = 128;
llvm::Type *HashTable = llvm::ArrayType::get(IntPtrTy, CacheSize);
llvm::Value *Cache = CGM.CreateRuntimeVariable(HashTable,
"__ubsan_vptr_type_cache");
llvm::Value *Slot = Builder.CreateAnd(Hash,
llvm::ConstantInt::get(IntPtrTy,
CacheSize-1));
llvm::Value *Indices[] = { Builder.getInt32(0), Slot };
llvm::Value *CacheVal =
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Builder.CreateAlignedLoad(Builder.CreateInBoundsGEP(Cache, Indices),
getPointerAlign());
[UBSan] Introduce type-based blacklisting. Teach UBSan vptr checker to ignore technically invalud down-casts on blacklisted types. Based on http://reviews.llvm.org/D4407 by Byoungyoung Lee! llvm-svn: 212770
2014-07-11 06:34:19 +08:00
// If the hash isn't in the cache, call a runtime handler to perform the
// hard work of checking whether the vptr is for an object of the right
// type. This will either fill in the cache and return, or produce a
// diagnostic.
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
llvm::Value *EqualHash = Builder.CreateICmpEQ(CacheVal, Hash);
[UBSan] Introduce type-based blacklisting. Teach UBSan vptr checker to ignore technically invalud down-casts on blacklisted types. Based on http://reviews.llvm.org/D4407 by Byoungyoung Lee! llvm-svn: 212770
2014-07-11 06:34:19 +08:00
llvm::Constant *StaticData[] = {
EmitCheckSourceLocation(Loc),
EmitCheckTypeDescriptor(Ty),
CGM.GetAddrOfRTTIDescriptor(Ty.getUnqualifiedType()),
llvm::ConstantInt::get(Int8Ty, TCK)
};
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *DynamicData[] = { Ptr, Hash };
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
EmitCheck(std::make_pair(EqualHash, SanitizerKind::Vptr),
"dynamic_type_cache_miss", StaticData, DynamicData);
[UBSan] Introduce type-based blacklisting. Teach UBSan vptr checker to ignore technically invalud down-casts on blacklisted types. Based on http://reviews.llvm.org/D4407 by Byoungyoung Lee! llvm-svn: 212770
2014-07-11 06:34:19 +08:00
}
-fcatch-undefined-behavior checking for appropriate vptr value: Clang CodeGen side. llvm-svn: 166661
2012-10-25 10:14:12 +08:00
}
ubsan: Add checking for invalid downcasts. Per [expr.static.cast]p2 and p11, base-to-derived casts have undefined behavior if the object is not actually an instance of the derived type. llvm-svn: 175078
2013-02-14 05:18:23 +08:00
if (Done) {
Builder.CreateBr(Done);
EmitBlock(Done);
}
Implement additional undefined checks for additional loads and stores. WIP. llvm-svn: 91498
2009-12-16 10:57:00 +08:00
}
Generalize RValue to handle complex better, generalize EmitCompoundStmt to support any sort of expr, add a new EmitAnyExpr routine. llvm-svn: 41660
2007-09-01 06:49:20 +08:00
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
/// Determine whether this expression refers to a flexible array member in a
/// struct. We disable array bounds checks for such members.
static bool isFlexibleArrayMemberExpr(const Expr *E) {
// For compatibility with existing code, we treat arrays of length 0 or
// 1 as flexible array members.
const ArrayType *AT = E->getType()->castAsArrayTypeUnsafe();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *CAT = dyn_cast<ConstantArrayType>(AT)) {
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
if (CAT->getSize().ugt(1))
return false;
} else if (!isa<IncompleteArrayType>(AT))
return false;
E = E->IgnoreParens();
// A flexible array member must be the last member in the class.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *ME = dyn_cast<MemberExpr>(E)) {
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
// FIXME: If the base type of the member expr is not FD->getParent(),
// this should not be treated as a flexible array member access.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *FD = dyn_cast<FieldDecl>(ME->getMemberDecl())) {
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
RecordDecl::field_iterator FI(
DeclContext::decl_iterator(const_cast<FieldDecl *>(FD)));
return ++FI == FD->getParent()->field_end();
}
}
return false;
}
/// If Base is known to point to the start of an array, return the length of
/// that array. Return 0 if the length cannot be determined.
Make helper function static. llvm-svn: 176767
2013-03-09 23:15:22 +08:00
static llvm::Value *getArrayIndexingBound(
CodeGenFunction &CGF, const Expr *Base, QualType &IndexedType) {
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
// For the vector indexing extension, the bound is the number of elements.
if (const VectorType *VT = Base->getType()->getAs<VectorType>()) {
IndexedType = Base->getType();
return CGF.Builder.getInt32(VT->getNumElements());
}
Base = Base->IgnoreParens();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *CE = dyn_cast<CastExpr>(Base)) {
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
if (CE->getCastKind() == CK_ArrayToPointerDecay &&
!isFlexibleArrayMemberExpr(CE->getSubExpr())) {
IndexedType = CE->getSubExpr()->getType();
const ArrayType *AT = IndexedType->castAsArrayTypeUnsafe();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *CAT = dyn_cast<ConstantArrayType>(AT))
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
return CGF.Builder.getInt(CAT->getSize());
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
else if (const auto *VAT = dyn_cast<VariableArrayType>(AT))
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
return CGF.getVLASize(VAT).first;
}
}
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
return nullptr;
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
}
void CodeGenFunction::EmitBoundsCheck(const Expr *E, const Expr *Base,
llvm::Value *Index, QualType IndexType,
bool Accessed) {
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
assert(SanOpts.has(SanitizerKind::ArrayBounds) &&
Split -fsanitize=bounds to -fsanitize=array-bounds (for the frontend-inserted check using the ubsan runtime) and -fsanitize=local-bounds (for the middle-end check which inserts traps). Remove -fsanitize=local-bounds from -fsanitize=undefined. It does not produce useful diagnostics and has false positives (PR17635), and is not a good compromise position between UBSan's checks and ASan's checks. Map -fbounds-checking to -fsanitize=local-bounds to restore Clang's historical behavior for that flag. llvm-svn: 193205
2013-10-23 06:51:04 +08:00
"should not be called unless adding bounds checks");
[UBSan] Add !nosanitize metadata to the code generated by UBSan. This is used to mark the instructions emitted by Clang to implement variety of UBSan checks. Generally, we don't want to instrument these instructions with another sanitizers (like ASan). Reviewed in http://reviews.llvm.org/D4544 llvm-svn: 213291
2014-07-18 02:46:27 +08:00
SanitizerScope SanScope(this);
PR15338: Don't assert if -fsanitize=bounds sees array indexing on an incomplete array type. llvm-svn: 175982
2013-02-24 09:56:24 +08:00
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
QualType IndexedType;
llvm::Value *Bound = getArrayIndexingBound(*this, Base, IndexedType);
if (!Bound)
return;
bool IndexSigned = IndexType->isSignedIntegerOrEnumerationType();
llvm::Value *IndexVal = Builder.CreateIntCast(Index, SizeTy, IndexSigned);
llvm::Value *BoundVal = Builder.CreateIntCast(Bound, SizeTy, false);
llvm::Constant *StaticData[] = {
EmitCheckSourceLocation(E->getExprLoc()),
EmitCheckTypeDescriptor(IndexedType),
EmitCheckTypeDescriptor(IndexType)
};
llvm::Value *Check = Accessed ? Builder.CreateICmpULT(IndexVal, BoundVal)
: Builder.CreateICmpULE(IndexVal, BoundVal);
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
EmitCheck(std::make_pair(Check, SanitizerKind::ArrayBounds), "out_of_bounds",
StaticData, Index);
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
}
refactor pre/postinc logic into CGF and require the caller to pass in the lvalue to poke, no functionality change. llvm-svn: 93075
2010-01-10 05:40:03 +08:00
CodeGenFunction::ComplexPairTy CodeGenFunction::
EmitComplexPrePostIncDec(const UnaryOperator *E, LValue LV,
bool isInc, bool isPre) {
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
ComplexPairTy InVal = EmitLoadOfComplex(LV, E->getExprLoc());
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
refactor pre/postinc logic into CGF and require the caller to pass in the lvalue to poke, no functionality change. llvm-svn: 93075
2010-01-10 05:40:03 +08:00
llvm::Value *NextVal;
if (isa<llvm::IntegerType>(InVal.first->getType())) {
uint64_t AmountVal = isInc ? 1 : -1;
NextVal = llvm::ConstantInt::get(InVal.first->getType(), AmountVal, true);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
refactor pre/postinc logic into CGF and require the caller to pass in the lvalue to poke, no functionality change. llvm-svn: 93075
2010-01-10 05:40:03 +08:00
// Add the inc/dec to the real part.
NextVal = Builder.CreateAdd(InVal.first, NextVal, isInc ? "inc" : "dec");
} else {
QualType ElemTy = E->getType()->getAs<ComplexType>()->getElementType();
llvm::APFloat FVal(getContext().getFloatTypeSemantics(ElemTy), 1);
if (!isInc)
FVal.changeSign();
NextVal = llvm::ConstantFP::get(getLLVMContext(), FVal);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
refactor pre/postinc logic into CGF and require the caller to pass in the lvalue to poke, no functionality change. llvm-svn: 93075
2010-01-10 05:40:03 +08:00
// Add the inc/dec to the real part.
NextVal = Builder.CreateFAdd(InVal.first, NextVal, isInc ? "inc" : "dec");
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
refactor pre/postinc logic into CGF and require the caller to pass in the lvalue to poke, no functionality change. llvm-svn: 93075
2010-01-10 05:40:03 +08:00
ComplexPairTy IncVal(NextVal, InVal.second);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
refactor pre/postinc logic into CGF and require the caller to pass in the lvalue to poke, no functionality change. llvm-svn: 93075
2010-01-10 05:40:03 +08:00
// Store the updated result through the lvalue.
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
EmitStoreOfComplex(IncVal, LV, /*init*/ false);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
refactor pre/postinc logic into CGF and require the caller to pass in the lvalue to poke, no functionality change. llvm-svn: 93075
2010-01-10 05:40:03 +08:00
// If this is a postinc, return the value read from memory, otherwise use the
// updated value.
return isPre ? IncVal : InVal;
}
Implement a trivial optimization to reduce the number of compares emitted. For: register short X; if (!X) { We now produce: %tmp = load i16* %X ; <i16> [#uses=1] %tobool = icmp ne i16 %tmp, 0 ; <i1> [#uses=1] %lnot = xor i1 %tobool, true ; <i1> [#uses=1] br i1 %lnot, label %ifthen, label %ifend instead of: %tmp = load i16* %X ; <i16> [#uses=1] %tobool = icmp ne i16 %tmp, 0 ; <i1> [#uses=1] %lnot = xor i1 %tobool, true ; <i1> [#uses=1] %lnot.ext = zext i1 %lnot to i32 ; <i32> [#uses=1] %tobool1 = icmp ne i32 %lnot.ext, 0 ; <i1> [#uses=1] br i1 %tobool1, label %ifthen, label %ifend llvm-svn: 39560
2007-06-03 03:47:04 +08:00
//===----------------------------------------------------------------------===//
Implement scaffolding for lvalues. Implement block vardecl lvalues. This allows us to translate: int func() { register int X; { int Y; return 1+X+Y; } } into: define i32 @func() { entry: %X = alloca i32 ; <i32*> [#uses=1] %Y = alloca i32 ; <i32*> [#uses=1] %allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0] %tmp = load i32* %X ; <i32> [#uses=1] %tmp1 = add i32 1, %tmp ; <i32> [#uses=1] %tmp2 = load i32* %Y ; <i32> [#uses=1] %tmp3 = add i32 %tmp1, %tmp2 ; <i32> [#uses=1] ret i32 %tmp3 ; No predecessors! ret i32 undef } llvm-svn: 39555
2007-06-02 13:24:33 +08:00
// LValue Expression Emission
Implement a trivial optimization to reduce the number of compares emitted. For: register short X; if (!X) { We now produce: %tmp = load i16* %X ; <i16> [#uses=1] %tobool = icmp ne i16 %tmp, 0 ; <i1> [#uses=1] %lnot = xor i1 %tobool, true ; <i1> [#uses=1] br i1 %lnot, label %ifthen, label %ifend instead of: %tmp = load i16* %X ; <i16> [#uses=1] %tobool = icmp ne i16 %tmp, 0 ; <i1> [#uses=1] %lnot = xor i1 %tobool, true ; <i1> [#uses=1] %lnot.ext = zext i1 %lnot to i32 ; <i32> [#uses=1] %tobool1 = icmp ne i32 %lnot.ext, 0 ; <i1> [#uses=1] br i1 %tobool1, label %ifthen, label %ifend llvm-svn: 39560
2007-06-03 03:47:04 +08:00
//===----------------------------------------------------------------------===//
Implement scaffolding for lvalues. Implement block vardecl lvalues. This allows us to translate: int func() { register int X; { int Y; return 1+X+Y; } } into: define i32 @func() { entry: %X = alloca i32 ; <i32*> [#uses=1] %Y = alloca i32 ; <i32*> [#uses=1] %allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0] %tmp = load i32* %X ; <i32> [#uses=1] %tmp1 = add i32 1, %tmp ; <i32> [#uses=1] %tmp2 = load i32* %Y ; <i32> [#uses=1] %tmp3 = add i32 %tmp1, %tmp2 ; <i32> [#uses=1] ret i32 %tmp3 ; No predecessors! ret i32 undef } llvm-svn: 39555
2007-06-02 13:24:33 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
/// EmitPointerWithAlignment - Given an expression of pointer type, try to
/// derive a more accurate bound on the alignment of the pointer.
Address CodeGenFunction::EmitPointerWithAlignment(const Expr *E,
AlignmentSource *Source) {
// We allow this with ObjC object pointers because of fragile ABIs.
assert(E->getType()->isPointerType() ||
E->getType()->isObjCObjectPointerType());
E = E->IgnoreParens();
// Casts:
if (const CastExpr *CE = dyn_cast<CastExpr>(E)) {
// Bind VLAs in the cast type.
if (E->getType()->isVariablyModifiedType())
EmitVariablyModifiedType(E->getType());
switch (CE->getCastKind()) {
// Non-converting casts (but not C's implicit conversion from void*).
case CK_BitCast:
case CK_NoOp:
if (auto PtrTy = CE->getSubExpr()->getType()->getAs<PointerType>()) {
if (PtrTy->getPointeeType()->isVoidType())
break;
AlignmentSource InnerSource;
Address Addr = EmitPointerWithAlignment(CE->getSubExpr(), &InnerSource);
if (Source) *Source = InnerSource;
// If this is an explicit bitcast, and the source l-value is
// opaque, honor the alignment of the casted-to type.
if (isa<ExplicitCastExpr>(CE) &&
CE->getCastKind() == CK_BitCast &&
InnerSource != AlignmentSource::Decl) {
Addr = Address(Addr.getPointer(),
getNaturalPointeeTypeAlignment(E->getType(), Source));
}
CodeGen: Add CFI unrelated cast checks to the new pointer code path. llvm-svn: 247105
2015-09-09 08:01:31 +08:00
if (SanOpts.has(SanitizerKind::CFIUnrelatedCast)) {
if (auto PT = E->getType()->getAs<PointerType>())
EmitVTablePtrCheckForCast(PT->getPointeeType(), Addr.getPointer(),
/*MayBeNull=*/true,
CodeGenFunction::CFITCK_UnrelatedCast,
CE->getLocStart());
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return Builder.CreateBitCast(Addr, ConvertType(E->getType()));
}
break;
// Array-to-pointer decay.
case CK_ArrayToPointerDecay:
return EmitArrayToPointerDecay(CE->getSubExpr(), Source);
// Derived-to-base conversions.
case CK_UncheckedDerivedToBase:
case CK_DerivedToBase: {
Address Addr = EmitPointerWithAlignment(CE->getSubExpr(), Source);
auto Derived = CE->getSubExpr()->getType()->getPointeeCXXRecordDecl();
return GetAddressOfBaseClass(Addr, Derived,
CE->path_begin(), CE->path_end(),
ShouldNullCheckClassCastValue(CE),
CE->getExprLoc());
}
// TODO: Is there any reason to treat base-to-derived conversions
// specially?
default:
break;
}
}
// Unary &.
if (const UnaryOperator *UO = dyn_cast<UnaryOperator>(E)) {
if (UO->getOpcode() == UO_AddrOf) {
LValue LV = EmitLValue(UO->getSubExpr());
if (Source) *Source = LV.getAlignmentSource();
return LV.getAddress();
}
}
// TODO: conditional operators, comma.
// Otherwise, use the alignment of the type.
CharUnits Align = getNaturalPointeeTypeAlignment(E->getType(), Source);
return Address(EmitScalarExpr(E), Align);
}
Pull CodeGenFunction::GetUndefRValue() out of EmitUnsupportedRValue. llvm-svn: 63845
2009-02-05 15:09:07 +08:00
RValue CodeGenFunction::GetUndefRValue(QualType Ty) {
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
if (Ty->isVoidType())
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
return RValue::get(nullptr);
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
switch (getEvaluationKind(Ty)) {
case TEK_Complex: {
llvm::Type *EltTy =
ConvertType(Ty->castAs<ComplexType>()->getElementType());
Update for LLVM API changes. llvm-svn: 77638
2009-07-31 07:11:26 +08:00
llvm::Value *U = llvm::UndefValue::get(EltTy);
Implement EmitUnsupportedRValue to generate an appropriately typed RValue. llvm-svn: 62004
2009-01-10 04:09:28 +08:00
return RValue::getComplex(std::make_pair(U, U));
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
fix rdar://8340348, a miscompile of boost that was exposed by r109848. That revision started classifying truly empty structs like "Y" and "X" as being NoClass/NoClass and turning them into 'ignore'. The call code turns around and allocates space for the ignored argument with GetUndefRValue. The bug is that GetUndefRValue would return the address as undef, instead of returning an object with a defined address but undefined contents. llvm-svn: 111794
2010-08-23 13:26:13 +08:00
// If this is a use of an undefined aggregate type, the aggregate must have an
// identifiable address. Just because the contents of the value are undefined
// doesn't mean that the address can't be taken and compared.
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
case TEK_Aggregate: {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address DestPtr = CreateMemTemp(Ty, "undef.agg.tmp");
fix rdar://8340348, a miscompile of boost that was exposed by r109848. That revision started classifying truly empty structs like "Y" and "X" as being NoClass/NoClass and turning them into 'ignore'. The call code turns around and allocates space for the ignored argument with GetUndefRValue. The bug is that GetUndefRValue would return the address as undef, instead of returning an object with a defined address but undefined contents. llvm-svn: 111794
2010-08-23 13:26:13 +08:00
return RValue::getAggregate(DestPtr);
Implement EmitUnsupportedRValue to generate an appropriately typed RValue. llvm-svn: 62004
2009-01-10 04:09:28 +08:00
}
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
case TEK_Scalar:
return RValue::get(llvm::UndefValue::get(ConvertType(Ty)));
}
llvm_unreachable("bad evaluation kind");
Give "unsupported" error on calls through block pointers instead of crashes. llvm-svn: 61992
2009-01-10 00:50:52 +08:00
}
Pull CodeGenFunction::GetUndefRValue() out of EmitUnsupportedRValue. llvm-svn: 63845
2009-02-05 15:09:07 +08:00
RValue CodeGenFunction::EmitUnsupportedRValue(const Expr *E,
const char *Name) {
ErrorUnsupported(E, Name);
return GetUndefRValue(E->getType());
}
Support __PRETTY_FUNCTION__ and friends in Obj-C methods. Add CodeGenFunction::EmitUnsupportedLValue - Gives error and returns undef value. Swap some asserts() over to using EmitUnsupportedLValue - Rumor has it users (and even some developers) prefer carat diagnostics to backtraces. - Works better in Release-Asserts to boot. llvm-svn: 55328
2008-08-26 04:45:57 +08:00
LValue CodeGenFunction::EmitUnsupportedLValue(const Expr *E,
const char *Name) {
ErrorUnsupported(E, Name);
Update for LLVM API change. llvm-svn: 77514
2009-07-30 06:16:19 +08:00
llvm::Type *Ty = llvm::PointerType::getUnqual(ConvertType(E->getType()));
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(Address(llvm::UndefValue::get(Ty), CharUnits::One()),
E->getType());
Support __PRETTY_FUNCTION__ and friends in Obj-C methods. Add CodeGenFunction::EmitUnsupportedLValue - Gives error and returns undef value. Swap some asserts() over to using EmitUnsupportedLValue - Rumor has it users (and even some developers) prefer carat diagnostics to backtraces. - Works better in Release-Asserts to boot. llvm-svn: 55328
2008-08-26 04:45:57 +08:00
}
-fcatch-undefined-behavior: Factor emission of the creation of, and branch to, the trap BB out of the individual checks and into a common function, to prepare for making this code call into a runtime library. Rename the existing EmitCheck to EmitTypeCheck to clarify it and to move it out of the way of the new EmitCheck. llvm-svn: 163451
2012-09-08 10:08:36 +08:00
LValue CodeGenFunction::EmitCheckedLValue(const Expr *E, TypeCheckKind TCK) {
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
LValue LV;
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
if (SanOpts.has(SanitizerKind::ArrayBounds) && isa<ArraySubscriptExpr>(E))
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
LV = EmitArraySubscriptExpr(cast<ArraySubscriptExpr>(E), /*Accessed*/true);
else
LV = EmitLValue(E);
IRgen: Move BitField LValues to just hold a reference to the CGBitFieldInfo. - Unfortunately, this requires some horrible code in CGObjCMac which always allocats a CGBitFieldInfo because we don't currently build a proper layout for Objective-C classes. It needs to be cleaned up, but I don't want the bit-field cleanups to be blocked on that. llvm-svn: 100474
2010-04-06 05:36:35 +08:00
if (!isa<DeclRefExpr>(E) && !LV.isBitField() && LV.isSimple())
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EmitTypeCheck(TCK, E->getExprLoc(), LV.getPointer(),
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
E->getType(), LV.getAlignment());
Implement additional undefined checks for additional loads and stores. WIP. llvm-svn: 91498
2009-12-16 10:57:00 +08:00
return LV;
}
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
/// EmitLValue - Emit code to compute a designator that specifies the location
/// of the expression.
///
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
/// This can return one of two things: a simple address or a bitfield reference.
/// In either case, the LLVM Value* in the LValue structure is guaranteed to be
/// an LLVM pointer type.
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
///
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
/// If this returns a bitfield reference, nothing about the pointee type of the
/// LLVM value is known: For example, it may not be a pointer to an integer.
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
///
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
/// If this returns a normal address, and if the lvalue's C type is fixed size,
/// this method guarantees that the returned pointer type will point to an LLVM
/// type of the same size of the lvalue's type. If the lvalue has a variable
/// length type, this is not possible.
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
///
Implement scaffolding for lvalues. Implement block vardecl lvalues. This allows us to translate: int func() { register int X; { int Y; return 1+X+Y; } } into: define i32 @func() { entry: %X = alloca i32 ; <i32*> [#uses=1] %Y = alloca i32 ; <i32*> [#uses=1] %allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0] %tmp = load i32* %X ; <i32> [#uses=1] %tmp1 = add i32 1, %tmp ; <i32> [#uses=1] %tmp2 = load i32* %Y ; <i32> [#uses=1] %tmp3 = add i32 %tmp1, %tmp2 ; <i32> [#uses=1] ret i32 %tmp3 ; No predecessors! ret i32 undef } llvm-svn: 39555
2007-06-02 13:24:33 +08:00
LValue CodeGenFunction::EmitLValue(const Expr *E) {
DebugInfo: Use the preferred location rather than the start location for expression line info This causes things like assignment to refer to the '=' rather than the LHS when attributing the store instruction, for example. There were essentially 3 options for this: * The beginning of an expression (this was the behavior prior to this commit). This meant that stepping through subexpressions would bounce around from subexpressions back to the start of the outer expression, etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be where the actual addition occurred)). * The end of an expression. This seems to be what GCC does /mostly/, and certainly this for function calls. This has the advantage that progress is always 'forwards' (never jumping backwards - except for independent subexpressions if they're evaluated in interesting orders, etc). "x + y + z" would go "x y z" with the additions occurring at y and z after the respective loads. The problem with this is that the user would still have to think fairly hard about precedence to realize which subexpression is being evaluated or which operator overload is being called in, say, an asan backtrace. * The preferred location or 'exprloc'. In this case you get sort of what you'd expect, though it's a bit confusing in its own way due to going 'backwards'. In this case the locations would be: "x y + z +" in lovely postfix arithmetic order. But this does mean that if the op+ were an operator overload, say, and in a backtrace, the backtrace will point to the exact '+' that's being called, not to the end of one of its operands. (actually the operator overload case doesn't work yet for other reasons, but that's being fixed - but this at least gets scalar/complex assignments and other plain operators right) llvm-svn: 227027
2015-01-25 09:19:10 +08:00
ApplyDebugLocation DL(*this, E);
Implement scaffolding for lvalues. Implement block vardecl lvalues. This allows us to translate: int func() { register int X; { int Y; return 1+X+Y; } } into: define i32 @func() { entry: %X = alloca i32 ; <i32*> [#uses=1] %Y = alloca i32 ; <i32*> [#uses=1] %allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0] %tmp = load i32* %X ; <i32> [#uses=1] %tmp1 = add i32 1, %tmp ; <i32> [#uses=1] %tmp2 = load i32* %Y ; <i32> [#uses=1] %tmp3 = add i32 %tmp1, %tmp2 ; <i32> [#uses=1] ret i32 %tmp3 ; No predecessors! ret i32 undef } llvm-svn: 39555
2007-06-02 13:24:33 +08:00
switch (E->getStmtClass()) {
Support __PRETTY_FUNCTION__ and friends in Obj-C methods. Add CodeGenFunction::EmitUnsupportedLValue - Gives error and returns undef value. Swap some asserts() over to using EmitUnsupportedLValue - Rumor has it users (and even some developers) prefer carat diagnostics to backtraces. - Works better in Release-Asserts to boot. llvm-svn: 55328
2008-08-26 04:45:57 +08:00
default: return EmitUnsupportedLValue(E, "l-value expression");
Implement scaffolding for lvalues. Implement block vardecl lvalues. This allows us to translate: int func() { register int X; { int Y; return 1+X+Y; } } into: define i32 @func() { entry: %X = alloca i32 ; <i32*> [#uses=1] %Y = alloca i32 ; <i32*> [#uses=1] %allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0] %tmp = load i32* %X ; <i32> [#uses=1] %tmp1 = add i32 1, %tmp ; <i32> [#uses=1] %tmp2 = load i32* %Y ; <i32> [#uses=1] %tmp3 = add i32 %tmp1, %tmp2 ; <i32> [#uses=1] ret i32 %tmp3 ; No predecessors! ret i32 undef } llvm-svn: 39555
2007-06-02 13:24:33 +08:00
Rip the ObjCPropertyRef l-value kind out of IR-generation. llvm-svn: 143908
2011-11-07 11:59:57 +08:00
case Expr::ObjCPropertyRefExprClass:
llvm_unreachable("cannot emit a property reference directly");
Objective-c++ IRGen. Support for @selector expression as an lvalue. Fixes PR7390. llvm-svn: 106235
2010-06-18 03:56:20 +08:00
case Expr::ObjCSelectorExprClass:
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
return EmitObjCSelectorLValue(cast<ObjCSelectorExpr>(E));
Code gen for ObjCIsaExpr AST used as lvalue. (fixes radar 7457534). llvm-svn: 90995
2009-12-10 07:35:29 +08:00
case Expr::ObjCIsaExprClass:
return EmitObjCIsaExpr(cast<ObjCIsaExpr>(E));
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
case Expr::BinaryOperatorClass:
Implement codegen of aggregates as lvalues in binary expressions, e.g. "(a = b).somefield". llvm-svn: 55758
2008-09-04 11:20:13 +08:00
return EmitBinaryOperatorLValue(cast<BinaryOperator>(E));
CodeGen: _Atomic(_Complex) shouldn't crash We could be a little kinder if we did a compare-exchange loop instead of an atomic-load/store pair. llvm-svn: 229212
2015-02-14 09:48:17 +08:00
case Expr::CompoundAssignOperatorClass: {
QualType Ty = E->getType();
if (const AtomicType *AT = Ty->getAs<AtomicType>())
Ty = AT->getValueType();
if (!Ty->isAnyComplexType())
Fix a bug in the emission of __real/__imag l-values on scalar operands. Fix a bug in the emission of complex compound assignment l-values. Introduce a method to emit an expression whose value isn't relevant. Make that method evaluate its operand as an l-value if it is one. Fixes our volatile compliance in C++. llvm-svn: 120931
2010-12-05 10:00:02 +08:00
return EmitCompoundAssignmentLValue(cast<CompoundAssignOperator>(E));
return EmitComplexCompoundAssignmentLValue(cast<CompoundAssignOperator>(E));
CodeGen: _Atomic(_Complex) shouldn't crash We could be a little kinder if we did a compare-exchange loop instead of an atomic-load/store pair. llvm-svn: 229212
2015-02-14 09:48:17 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
case Expr::CallExprClass:
Handle member expressions that return references correctly. llvm-svn: 80723
2009-09-02 05:18:52 +08:00
case Expr::CXXMemberCallExprClass:
Add a new expression node, CXXOperatorCallExpr, which expresses a function call created in response to the use of operator syntax that resolves to an overloaded operator in C++, e.g., "str1 + str2" that resolves to std::operator+(str1, str2)". We now build a CXXOperatorCallExpr in C++ when we pick an overloaded operator. (But only for binary operators, where we actually implement overloading) I decided *not* to refactor the current CallExpr to make it abstract (with FunctionCallExpr and CXXOperatorCallExpr as derived classes). Doing so would allow us to make CXXOperatorCallExpr a little bit smaller, at the cost of making the argument and callee accessors virtual. We won't know if this is going to be a win until we can parse lots of C++ code to determine how much memory we'll save by making this change vs. the performance penalty due to the extra virtual calls. llvm-svn: 59306
2008-11-15 00:09:21 +08:00
case Expr::CXXOperatorCallExprClass:
AST representation for user-defined literals, plus just enough of semantic analysis to make the AST representation testable. They are represented by a new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic properties, including full CodeGen support, are achieved for free by this representation. UserDefinedLiterals can never be dependent, so no custom instantiation behavior is required. They are mangled as if they were direct calls to the underlying literal operator. This matches g++'s apparent behavior (but not its actual mangling, which is broken for literal-operator-ids). User-defined *string* literals are now fully-operational, but the semantic analysis is quite hacky and needs more work. No other forms of user-defined literal are created yet, but the AST support for them is present. This patch committed after midnight because we had already hit the quota for new kinds of literal yesterday. llvm-svn: 152211
2012-03-07 16:35:16 +08:00
case Expr::UserDefinedLiteralClass:
Add a new expression node, CXXOperatorCallExpr, which expresses a function call created in response to the use of operator syntax that resolves to an overloaded operator in C++, e.g., "str1 + str2" that resolves to std::operator+(str1, str2)". We now build a CXXOperatorCallExpr in C++ when we pick an overloaded operator. (But only for binary operators, where we actually implement overloading) I decided *not* to refactor the current CallExpr to make it abstract (with FunctionCallExpr and CXXOperatorCallExpr as derived classes). Doing so would allow us to make CXXOperatorCallExpr a little bit smaller, at the cost of making the argument and callee accessors virtual. We won't know if this is going to be a win until we can parse lots of C++ code to determine how much memory we'll save by making this change vs. the performance penalty due to the extra virtual calls. llvm-svn: 59306
2008-11-15 00:09:21 +08:00
return EmitCallExprLValue(cast<CallExpr>(E));
Support IRgen of va_arg of structure as l-value. llvm-svn: 64325
2009-02-12 04:59:32 +08:00
case Expr::VAArgExprClass:
return EmitVAArgExprLValue(cast<VAArgExpr>(E));
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
case Expr::DeclRefExprClass:
Add QualifiedDeclRefExpr, which retains additional source-location information for declarations that were referenced via a qualified-id, e.g., N::C::value. We keep track of the location of the start of the nested-name-specifier. Note that the difference between QualifiedDeclRefExpr and DeclRefExpr does have an effect on the semantics of function calls in two ways: 1) The use of a qualified-id instead of an unqualified-id suppresses argument-dependent lookup 2) If the name refers to a virtual function, the qualified-id version will call the function determined statically while the unqualified-id version will call the function determined dynamically (by looking up the appropriate function in the vtable). Neither of these features is implemented yet, but we do print out qualified names for QualifiedDeclRefExprs as part of the AST printing. llvm-svn: 61789
2009-01-06 13:10:23 +08:00
return EmitDeclRefLValue(cast<DeclRefExpr>(E));
Formatting. llvm-svn: 139296
2011-09-09 01:15:04 +08:00
case Expr::ParenExprClass:
return EmitLValue(cast<ParenExpr>(E)->getSubExpr());
C1X: implement generic selections As an extension, generic selection support has been added for all supported languages. The syntax is the same as for C1X. llvm-svn: 129554
2011-04-15 08:35:48 +08:00
case Expr::GenericSelectionExprClass:
return EmitLValue(cast<GenericSelectionExpr>(E)->getResultExpr());
rename PreDefinedExpr -> PredefinedExpr llvm-svn: 54605
2008-08-10 09:53:14 +08:00
case Expr::PredefinedExprClass:
return EmitPredefinedLValue(cast<PredefinedExpr>(E));
implement codegen of string literals. llvm-svn: 39597
2007-06-06 12:54:52 +08:00
case Expr::StringLiteralClass:
return EmitStringLiteralLValue(cast<StringLiteral>(E));
first wave of fixes for @encode sema support. This is part of PR3648. The big difference here is that (like string literal) @encode has array type, not pointer type. llvm-svn: 65391
2009-02-25 06:18:39 +08:00
case Expr::ObjCEncodeExprClass:
return EmitObjCEncodeExprLValue(cast<ObjCEncodeExpr>(E));
Change the AST representation of operations on Objective-C property references to use a new PseudoObjectExpr expression which pairs a syntactic form of the expression with a set of semantic expressions implementing it. This should significantly reduce the complexity required elsewhere in the compiler to deal with these kinds of expressions (e.g. IR generation's special l-value kind, the static analyzer's Message abstraction), at the lower cost of specifically dealing with the odd AST structure of these expressions. It should also greatly simplify efforts to implement similar language features in the future, most notably Managed C++'s properties and indexed properties. Most of the effort here is in dealing with the various clients of the AST. I've gone ahead and simplified the ObjC rewriter's use of properties; other clients, like IR-gen and the static analyzer, have all the old complexity *and* all the new complexity, at least temporarily. Many thanks to Ted for writing and advising on the necessary changes to the static analyzer. I've xfailed a small diagnostics regression in the static analyzer at Ted's request. llvm-svn: 143867
2011-11-06 17:01:30 +08:00
case Expr::PseudoObjectExprClass:
return EmitPseudoObjectLValue(cast<PseudoObjectExpr>(E));
Reference initialization with initializer lists. This supports single-element initializer lists for references according to DR1288, as well as creating temporaries and binding to them for other initializer lists. llvm-svn: 145186
2011-11-28 00:50:07 +08:00
case Expr::InitListExprClass:
Implement IRGen for C++11's "T{1, 2, 3}", where T is an aggregate and the expression is treated as an lvalue. llvm-svn: 156781
2012-05-15 05:57:21 +08:00
return EmitInitListLValue(cast<InitListExpr>(E));
More temporary support. llvm-svn: 72648
2009-05-31 07:23:33 +08:00
case Expr::CXXTemporaryObjectExprClass:
case Expr::CXXConstructExprClass:
Add lvalue irgen support for CXXBindTemporaryExpr. llvm-svn: 72649
2009-05-31 07:30:54 +08:00
return EmitCXXConstructLValue(cast<CXXConstructExpr>(E));
case Expr::CXXBindTemporaryExprClass:
return EmitCXXBindTemporaryLValue(cast<CXXBindTemporaryExpr>(E));
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
case Expr::CXXUuidofExprClass:
return EmitCXXUuidofLValue(cast<CXXUuidofExpr>(E));
A little bit of lambda IRGen. llvm-svn: 150058
2012-02-08 13:34:55 +08:00
case Expr::LambdaExprClass:
return EmitLambdaLValue(cast<LambdaExpr>(E));
Enter the cleanups for a block outside the enclosing full-expression. Naturally they're inactive before we enter the block literal expression. This restores the intended behavior that blocks belong to their enclosing scope. There's a useful -O0 / compile-time optimization that we're missing here with activating cleanups following straight-line code from their inactive beginnings. llvm-svn: 144268
2011-11-10 16:15:53 +08:00
case Expr::ExprWithCleanupsClass: {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *cleanups = cast<ExprWithCleanups>(E);
Enter the cleanups for a block outside the enclosing full-expression. Naturally they're inactive before we enter the block literal expression. This restores the intended behavior that blocks belong to their enclosing scope. There's a useful -O0 / compile-time optimization that we're missing here with activating cleanups following straight-line code from their inactive beginnings. llvm-svn: 144268
2011-11-10 16:15:53 +08:00
enterFullExpression(cleanups);
RunCleanupsScope Scope(*this);
return EmitLValue(cleanups->getSubExpr());
}
Handle CXXDefaultArgExprs in EmitLValue. Fixes PR5484. llvm-svn: 88735
2009-11-14 09:51:50 +08:00
case Expr::CXXDefaultArgExprClass:
return EmitLValue(cast<CXXDefaultArgExpr>(E)->getExpr());
C++1y: Allow aggregates to have default initializers. Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in CXXCtorInitializers and in InitListExprs to represent a default initializer. There's an additional complication here: because the default initializer can refer to the initialized object via its 'this' pointer, we need to make sure that 'this' points to the right thing within the evaluation. llvm-svn: 179958
2013-04-21 06:23:05 +08:00
case Expr::CXXDefaultInitExprClass: {
CXXDefaultInitExprScope Scope(*this);
return EmitLValue(cast<CXXDefaultInitExpr>(E)->getExpr());
}
Implement typeid for class types. llvm-svn: 88843
2009-11-15 16:09:41 +08:00
case Expr::CXXTypeidExprClass:
return EmitCXXTypeidLValue(cast<CXXTypeidExpr>(E));
Add lvalue irgen support for CXXBindTemporaryExpr. llvm-svn: 72649
2009-05-31 07:30:54 +08:00
Implement Obj-C ivar references to aggregates. Implement Obj-C lvalue message sends (aggregate returns). Update several places to emit more precise ErrorUnsupported warnings for currently unimplemented Obj-C features (main missing chunks are property references, Obj-C exception handling, and the for ... in syntax). llvm-svn: 55234
2008-08-23 18:51:21 +08:00
case Expr::ObjCMessageExprClass:
return EmitObjCMessageExprLValue(cast<ObjCMessageExpr>(E));
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
case Expr::ObjCIvarRefExprClass:
Add initial support for objc codegen for methods, ivars, and the etoile runtime, patch by David Chisnall! llvm-svn: 48969
2008-03-31 07:03:07 +08:00
return EmitObjCIvarRefLValue(cast<ObjCIvarRefExpr>(E));
fix PR4067: [Linux kernel] cannot aggregate codegen stmtexpr as lvalue llvm-svn: 70067
2009-04-26 03:35:26 +08:00
case Expr::StmtExprClass:
return EmitStmtExprLValue(cast<StmtExpr>(E));
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
case Expr::UnaryOperatorClass:
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
return EmitUnaryOpLValue(cast<UnaryOperator>(E));
Implement array subscripts for non-vla types. llvm-svn: 39622
2007-06-09 07:31:14 +08:00
case Expr::ArraySubscriptExprClass:
return EmitArraySubscriptExpr(cast<ArraySubscriptExpr>(E));
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
case Expr::OMPArraySectionExprClass:
return EmitOMPArraySectionExpr(cast<OMPArraySectionExpr>(E));
OCUVector -> ExtVector, shorthand for extended vector, per feedback from Chris. llvm-svn: 49942
2008-04-19 07:10:10 +08:00
case Expr::ExtVectorElementExprClass:
return EmitExtVectorElementExpr(cast<ExtVectorElementExpr>(E));
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
case Expr::MemberExprClass:
When a member reference expression includes a qualifier on the member name, e.g., x->Base::f() retain the qualifier (and its source range information) in a new subclass of MemberExpr called CXXQualifiedMemberExpr. Provide construction, transformation, profiling, printing, etc., for this new expression type. When a virtual function is called via a qualified name, don't emit a virtual call. Instead, call that function directly. Mike, could you add a CodeGen test for this, too? llvm-svn: 80167
2009-08-27 06:36:53 +08:00
return EmitMemberExpr(cast<MemberExpr>(E));
Add codegen support for block-level compound literals. llvm-svn: 51081
2008-05-14 07:18:27 +08:00
case Expr::CompoundLiteralExprClass:
return EmitCompoundLiteralLValue(cast<CompoundLiteralExpr>(E));
Support member reference on ?: of struct type. llvm-svn: 67603
2009-03-24 10:38:23 +08:00
case Expr::ConditionalOperatorClass:
Code generation of Conditional operators that are lvalues (but that aren't bitfields). llvm-svn: 81867
2009-09-16 00:35:24 +08:00
return EmitConditionalOperatorLValue(cast<ConditionalOperator>(E));
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
case Expr::BinaryConditionalOperatorClass:
return EmitConditionalOperatorLValue(cast<BinaryConditionalOperator>(E));
Fix rdar://6095061 - gcc allows __builtin_choose_expr as an lvalue llvm-svn: 60924
2008-12-12 13:35:08 +08:00
case Expr::ChooseExprClass:
Make IgnoreParens() look through ChooseExprs. This is the same way GenericSelectionExpr works, and it's generally a more consistent approach. A large part of this patch is devoted to caching the value of the condition of a ChooseExpr; it's needed to avoid threading an ASTContext into IgnoreParens(). Fixes <rdar://problem/14438917>. llvm-svn: 186738
2013-07-20 08:40:58 +08:00
return EmitLValue(cast<ChooseExpr>(E)->getChosenSubExpr());
Save a copy expression for non-trivial copy constructions of catch variables. llvm-svn: 125661
2011-02-16 16:02:54 +08:00
case Expr::OpaqueValueExprClass:
return EmitOpaqueValueLValue(cast<OpaqueValueExpr>(E));
Create a new expression node, SubstNonTypeTemplateParmExpr, to represent a fully-substituted non-type template parameter. This should improve source fidelity, as well as being generically useful for diagnostics and such. llvm-svn: 135243
2011-07-15 13:09:51 +08:00
case Expr::SubstNonTypeTemplateParmExprClass:
return EmitLValue(cast<SubstNonTypeTemplateParmExpr>(E)->getReplacement());
teach codegen to handle noop casts as lvalues. llvm-svn: 67164
2009-03-18 12:02:57 +08:00
case Expr::ImplicitCastExprClass:
case Expr::CStyleCastExprClass:
case Expr::CXXFunctionalCastExprClass:
case Expr::CXXStaticCastExprClass:
case Expr::CXXDynamicCastExprClass:
case Expr::CXXReinterpretCastExprClass:
case Expr::CXXConstCastExprClass:
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
case Expr::ObjCBridgedCastExprClass:
add codegen support for casting an element to a union. There are some more complex cases (_Complex and structs) that I'm still working on. llvm-svn: 67218
2009-03-19 02:28:57 +08:00
return EmitCastLValue(cast<CastExpr>(E));
Reference initialization with initializer lists. This supports single-element initializer lists for references according to DR1288, as well as creating temporaries and binding to them for other initializer lists. llvm-svn: 145186
2011-11-28 00:50:07 +08:00
Introduce a new AST node describing reference binding to temporaries. MaterializeTemporaryExpr captures a reference binding to a temporary value, making explicit that the temporary value (a prvalue) needs to be materialized into memory so that its address can be used. The intended AST invariant here is that a reference will always bind to a glvalue, and MaterializeTemporaryExpr will be used to convert prvalues into glvalues for that binding to happen. For example, given const int& r = 1.0; The initializer of "r" will be a MaterializeTemporaryExpr whose subexpression is an implicit conversion from the double literal "1.0" to an integer value. IR generation benefits most from this new node, since it was previously guessing (badly) when to materialize temporaries for the purposes of reference binding. There are likely more refactoring and cleanups we could perform there, but the introduction of MaterializeTemporaryExpr fixes PR9565, a case where IR generation would effectively bind a const reference directly to a bitfield in a struct. Addresses <rdar://problem/9552231>. llvm-svn: 133521
2011-06-22 01:03:29 +08:00
case Expr::MaterializeTemporaryExprClass:
return EmitMaterializeTemporaryExpr(cast<MaterializeTemporaryExpr>(E));
Implement scaffolding for lvalues. Implement block vardecl lvalues. This allows us to translate: int func() { register int X; { int Y; return 1+X+Y; } } into: define i32 @func() { entry: %X = alloca i32 ; <i32*> [#uses=1] %Y = alloca i32 ; <i32*> [#uses=1] %allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0] %tmp = load i32* %X ; <i32> [#uses=1] %tmp1 = add i32 1, %tmp ; <i32> [#uses=1] %tmp2 = load i32* %Y ; <i32> [#uses=1] %tmp3 = add i32 %tmp1, %tmp2 ; <i32> [#uses=1] ret i32 %tmp3 ; No predecessors! ret i32 undef } llvm-svn: 39555
2007-06-02 13:24:33 +08:00
}
}
Unify the BlockDeclRefExpr and DeclRefExpr paths so that we correctly emit loads of BlockDeclRefExprs even when they don't qualify as ODR-uses. I think I'm adequately convinced that BlockDeclRefExpr can die. llvm-svn: 152479
2012-03-10 11:05:10 +08:00
/// Given an object of the given canonical type, can we safely copy a
/// value out of it based on its initializer?
static bool isConstantEmittableObjectType(QualType type) {
assert(type.isCanonical());
assert(!type->isReferenceType());
// Must be const-qualified but non-volatile.
Qualifiers qs = type.getLocalQualifiers();
if (!qs.hasConst() || qs.hasVolatile()) return false;
// Otherwise, all object types satisfy this except C++ classes with
// mutable subobjects or non-trivial copy/destroy behavior.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *RT = dyn_cast<RecordType>(type))
if (const auto *RD = dyn_cast<CXXRecordDecl>(RT->getDecl()))
Unify the BlockDeclRefExpr and DeclRefExpr paths so that we correctly emit loads of BlockDeclRefExprs even when they don't qualify as ODR-uses. I think I'm adequately convinced that BlockDeclRefExpr can die. llvm-svn: 152479
2012-03-10 11:05:10 +08:00
if (RD->hasMutableFields() || !RD->isTrivial())
return false;
return true;
}
/// Can we constant-emit a load of a reference to a variable of the
/// given type? This is different from predicates like
/// Decl::isUsableInConstantExpressions because we do want it to apply
/// in situations that don't necessarily satisfy the language's rules
/// for this (e.g. C++'s ODR-use rules). For example, we want to able
/// to do this with const float variables even if those variables
/// aren't marked 'constexpr'.
enum ConstantEmissionKind {
CEK_None,
CEK_AsReferenceOnly,
CEK_AsValueOrReference,
CEK_AsValueOnly
};
static ConstantEmissionKind checkVarTypeForConstantEmission(QualType type) {
type = type.getCanonicalType();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *ref = dyn_cast<ReferenceType>(type)) {
Unify the BlockDeclRefExpr and DeclRefExpr paths so that we correctly emit loads of BlockDeclRefExprs even when they don't qualify as ODR-uses. I think I'm adequately convinced that BlockDeclRefExpr can die. llvm-svn: 152479
2012-03-10 11:05:10 +08:00
if (isConstantEmittableObjectType(ref->getPointeeType()))
return CEK_AsValueOrReference;
return CEK_AsReferenceOnly;
}
if (isConstantEmittableObjectType(type))
return CEK_AsValueOnly;
return CEK_None;
}
/// Try to emit a reference to the given value without producing it as
/// an l-value. This is actually more than an optimization: we can't
/// produce an l-value for variables that we never actually captured
/// in a block or lambda, which means const int variables or constexpr
/// literals or similar.
CodeGenFunction::ConstantEmission
Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to track whether the referenced declaration comes from an enclosing local context. I'm amenable to suggestions about the exact meaning of this bit. llvm-svn: 152491
2012-03-10 17:33:50 +08:00
CodeGenFunction::tryEmitAsConstant(DeclRefExpr *refExpr) {
ValueDecl *value = refExpr->getDecl();
Unify the BlockDeclRefExpr and DeclRefExpr paths so that we correctly emit loads of BlockDeclRefExprs even when they don't qualify as ODR-uses. I think I'm adequately convinced that BlockDeclRefExpr can die. llvm-svn: 152479
2012-03-10 11:05:10 +08:00
// The value needs to be an enum constant or a constant variable.
ConstantEmissionKind CEK;
if (isa<ParmVarDecl>(value)) {
CEK = CEK_None;
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
} else if (auto *var = dyn_cast<VarDecl>(value)) {
Unify the BlockDeclRefExpr and DeclRefExpr paths so that we correctly emit loads of BlockDeclRefExprs even when they don't qualify as ODR-uses. I think I'm adequately convinced that BlockDeclRefExpr can die. llvm-svn: 152479
2012-03-10 11:05:10 +08:00
CEK = checkVarTypeForConstantEmission(var->getType());
} else if (isa<EnumConstantDecl>(value)) {
CEK = CEK_AsValueOnly;
} else {
CEK = CEK_None;
}
if (CEK == CEK_None) return ConstantEmission();
Expr::EvalResult result;
bool resultIsReference;
QualType resultType;
// It's best to evaluate all the way as an r-value if that's permitted.
if (CEK != CEK_AsReferenceOnly &&
Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to track whether the referenced declaration comes from an enclosing local context. I'm amenable to suggestions about the exact meaning of this bit. llvm-svn: 152491
2012-03-10 17:33:50 +08:00
refExpr->EvaluateAsRValue(result, getContext())) {
Unify the BlockDeclRefExpr and DeclRefExpr paths so that we correctly emit loads of BlockDeclRefExprs even when they don't qualify as ODR-uses. I think I'm adequately convinced that BlockDeclRefExpr can die. llvm-svn: 152479
2012-03-10 11:05:10 +08:00
resultIsReference = false;
resultType = refExpr->getType();
// Otherwise, try to evaluate as an l-value.
} else if (CEK != CEK_AsValueOnly &&
Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to track whether the referenced declaration comes from an enclosing local context. I'm amenable to suggestions about the exact meaning of this bit. llvm-svn: 152491
2012-03-10 17:33:50 +08:00
refExpr->EvaluateAsLValue(result, getContext())) {
Unify the BlockDeclRefExpr and DeclRefExpr paths so that we correctly emit loads of BlockDeclRefExprs even when they don't qualify as ODR-uses. I think I'm adequately convinced that BlockDeclRefExpr can die. llvm-svn: 152479
2012-03-10 11:05:10 +08:00
resultIsReference = true;
resultType = value->getType();
// Failure.
} else {
return ConstantEmission();
}
// In any case, if the initializer has side-effects, abandon ship.
if (result.HasSideEffects)
return ConstantEmission();
// Emit as a constant.
llvm::Constant *C = CGM.EmitConstantValue(result.Val, resultType, this);
Revert r189649 because it was breaking sanitizer bots. llvm-svn: 189660
2013-08-30 16:53:09 +08:00
// Make sure we emit a debug reference to the global variable.
// This should probably fire even for
if (isa<VarDecl>(value)) {
if (!getContext().DeclMustBeEmitted(cast<VarDecl>(value)))
EmitDeclRefExprDbgValue(refExpr, C);
} else {
assert(isa<EnumConstantDecl>(value));
EmitDeclRefExprDbgValue(refExpr, C);
}
Unify the BlockDeclRefExpr and DeclRefExpr paths so that we correctly emit loads of BlockDeclRefExprs even when they don't qualify as ODR-uses. I think I'm adequately convinced that BlockDeclRefExpr can die. llvm-svn: 152479
2012-03-10 11:05:10 +08:00
// If we emitted a reference constant, we need to dereference that.
if (resultIsReference)
return ConstantEmission::forReference(C);
return ConstantEmission::forValue(C);
}
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
llvm::Value *CodeGenFunction::EmitLoadOfScalar(LValue lvalue,
SourceLocation Loc) {
Restore correct use of GC barriers. llvm-svn: 133144
2011-06-16 12:16:24 +08:00
return EmitLoadOfScalar(lvalue.getAddress(), lvalue.isVolatile(),
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
lvalue.getType(), Loc, lvalue.getAlignmentSource(),
lvalue.getTBAAInfo(),
Introduce __builtin_nontemporal_store and __builtin_nontemporal_load. Summary: Currently clang provides no general way to generate nontemporal loads/stores. There are some architecture specific builtins for doing so (e.g. in x86), but there is no way to generate non-temporal store on, e.g. AArch64. This patch adds generic builtins which are expanded to a simple store with '!nontemporal' attribute in IR. Differential Revision: http://reviews.llvm.org/D12313 llvm-svn: 247104
2015-09-09 07:52:33 +08:00
lvalue.getTBAABaseType(), lvalue.getTBAAOffset(),
lvalue.isNontemporal());
Restore correct use of GC barriers. llvm-svn: 133144
2011-06-16 12:16:24 +08:00
}
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
static bool hasBooleanRepresentation(QualType Ty) {
if (Ty->isBooleanType())
return true;
if (const EnumType *ET = Ty->getAs<EnumType>())
return ET->getDecl()->getIntegerType()->isBooleanType();
Fix some i1/i8 confusion within _Atomic(bool) in IR generation, both in general (such an atomic has boolean representation) and specifically for IR generation of __c11_atomic_init. The latter also means actually using initialization semantics for this initialization, rather than just creating a store. On a related note, make sure we actually put in non-atomic-to-atomic conversions when performing an implicit conversion sequence. IR generation is far too kind here, but we still want the ASTs to make sense. llvm-svn: 154612
2012-04-13 04:42:30 +08:00
if (const AtomicType *AT = Ty->getAs<AtomicType>())
return hasBooleanRepresentation(AT->getValueType());
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
return false;
}
ubsan: Add -fsanitize=bool and -fsanitize=enum, which check for loads of bit-patterns which are not valid values for enumerated or boolean types. These checks are the ubsan analogue of !range metadata. llvm-svn: 170108
2012-12-13 15:11:50 +08:00
static bool getRangeForType(CodeGenFunction &CGF, QualType Ty,
llvm::APInt &Min, llvm::APInt &End,
bool StrictEnums) {
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
const EnumType *ET = Ty->getAs<EnumType>();
ubsan: Add -fsanitize=bool and -fsanitize=enum, which check for loads of bit-patterns which are not valid values for enumerated or boolean types. These checks are the ubsan analogue of !range metadata. llvm-svn: 170108
2012-12-13 15:11:50 +08:00
bool IsRegularCPlusPlusEnum = CGF.getLangOpts().CPlusPlus && StrictEnums &&
ET && !ET->getDecl()->isFixed();
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
bool IsBool = hasBooleanRepresentation(Ty);
if (!IsBool && !IsRegularCPlusPlusEnum)
ubsan: Add -fsanitize=bool and -fsanitize=enum, which check for loads of bit-patterns which are not valid values for enumerated or boolean types. These checks are the ubsan analogue of !range metadata. llvm-svn: 170108
2012-12-13 15:11:50 +08:00
return false;
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
if (IsBool) {
ubsan: Add -fsanitize=bool and -fsanitize=enum, which check for loads of bit-patterns which are not valid values for enumerated or boolean types. These checks are the ubsan analogue of !range metadata. llvm-svn: 170108
2012-12-13 15:11:50 +08:00
Min = llvm::APInt(CGF.getContext().getTypeSize(Ty), 0);
End = llvm::APInt(CGF.getContext().getTypeSize(Ty), 2);
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
} else {
const EnumDecl *ED = ET->getDecl();
ubsan: Add -fsanitize=bool and -fsanitize=enum, which check for loads of bit-patterns which are not valid values for enumerated or boolean types. These checks are the ubsan analogue of !range metadata. llvm-svn: 170108
2012-12-13 15:11:50 +08:00
llvm::Type *LTy = CGF.ConvertTypeForMem(ED->getIntegerType());
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
unsigned Bitwidth = LTy->getScalarSizeInBits();
unsigned NumNegativeBits = ED->getNumNegativeBits();
unsigned NumPositiveBits = ED->getNumPositiveBits();
if (NumNegativeBits) {
unsigned NumBits = std::max(NumNegativeBits, NumPositiveBits + 1);
assert(NumBits <= Bitwidth);
End = llvm::APInt(Bitwidth, 1) << (NumBits - 1);
Min = -End;
} else {
assert(NumPositiveBits <= Bitwidth);
End = llvm::APInt(Bitwidth, 1) << NumPositiveBits;
Min = llvm::APInt(Bitwidth, 0);
}
}
ubsan: Add -fsanitize=bool and -fsanitize=enum, which check for loads of bit-patterns which are not valid values for enumerated or boolean types. These checks are the ubsan analogue of !range metadata. llvm-svn: 170108
2012-12-13 15:11:50 +08:00
return true;
}
llvm::MDNode *CodeGenFunction::getRangeForLoadFromType(QualType Ty) {
llvm::APInt Min, End;
if (!getRangeForType(*this, Ty, Min, End,
CGM.getCodeGenOpts().StrictEnums))
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
return nullptr;
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
Use MDBuilder to help with metadata creation. llvm-svn: 154767
2012-04-16 02:04:54 +08:00
llvm::MDBuilder MDHelper(getLLVMContext());
Adjust for LLVM name tweaks requested by Chandler. llvm-svn: 154824
2012-04-17 00:29:47 +08:00
return MDHelper.createRange(Min, End);
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *CodeGenFunction::EmitLoadOfScalar(Address Addr, bool Volatile,
QualType Ty,
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
SourceLocation Loc,
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
AlignmentSource AlignSource,
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
llvm::MDNode *TBAAInfo,
QualType TBAABaseType,
Introduce __builtin_nontemporal_store and __builtin_nontemporal_load. Summary: Currently clang provides no general way to generate nontemporal loads/stores. There are some architecture specific builtins for doing so (e.g. in x86), but there is no way to generate non-temporal store on, e.g. AArch64. This patch adds generic builtins which are expanded to a simple store with '!nontemporal' attribute in IR. Differential Revision: http://reviews.llvm.org/D12313 llvm-svn: 247104
2015-09-09 07:52:33 +08:00
uint64_t TBAAOffset,
bool isNontemporal) {
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
// For better performance, handle vector loads differently.
if (Ty->isVectorType()) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
const llvm::Type *EltTy = Addr.getElementType();
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *VTy = cast<llvm::VectorType>(EltTy);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// Handle vectors of size 3 like size 4 for better performance.
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
if (VTy->getNumElements() == 3) {
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
// Bitcast to vec4 type.
llvm::VectorType *vec4Ty = llvm::VectorType::get(VTy->getElementType(),
4);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Cast = Builder.CreateElementBitCast(Addr, vec4Ty, "castToVec4");
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
// Now load value.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *V = Builder.CreateLoad(Cast, Volatile, "loadVec4");
Simplify. No functionality change. llvm-svn: 170100
2012-12-13 13:41:48 +08:00
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
// Shuffle vector to get vec3.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
V = Builder.CreateShuffleVector(V, llvm::UndefValue::get(vec4Ty),
[CodeGen] Simplify creation of shuffle masks. No functional change intended. llvm-svn: 243439
2015-07-29 00:25:32 +08:00
{0, 1, 2}, "extractVec");
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
return EmitFromMemory(V, Ty);
}
}
Promote atomic type sizes up to a power of two, capped by MaxAtomicPromoteWidth. Fix a ton of terrible bugs with _Atomic types and (non-intrinsic-mediated) loads and stores thereto. llvm-svn: 176658
2013-03-08 05:37:17 +08:00
// Atomic operations have to be done on integral types.
Revert "Revert r229082 for a bit, it caused PR22577." This reverts commit r229123. It was a red herring, the bug was present without r229082. llvm-svn: 229205
2015-02-14 09:35:12 +08:00
if (Ty->isAtomicType() || typeIsSuitableForInlineAtomic(Ty, Volatile)) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue lvalue =
LValue::MakeAddr(Addr, Ty, getContext(), AlignSource, TBAAInfo);
Try to unbreak the Hexagon bot llvm-svn: 229219
2015-02-14 10:18:14 +08:00
return EmitAtomicLoad(lvalue, Loc).getScalarVal();
Promote atomic type sizes up to a power of two, capped by MaxAtomicPromoteWidth. Fix a ton of terrible bugs with _Atomic types and (non-intrinsic-mediated) loads and stores thereto. llvm-svn: 176658
2013-03-08 05:37:17 +08:00
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::LoadInst *Load = Builder.CreateLoad(Addr, Volatile);
Introduce __builtin_nontemporal_store and __builtin_nontemporal_load. Summary: Currently clang provides no general way to generate nontemporal loads/stores. There are some architecture specific builtins for doing so (e.g. in x86), but there is no way to generate non-temporal store on, e.g. AArch64. This patch adds generic builtins which are expanded to a simple store with '!nontemporal' attribute in IR. Differential Revision: http://reviews.llvm.org/D12313 llvm-svn: 247104
2015-09-09 07:52:33 +08:00
if (isNontemporal) {
llvm::MDNode *Node = llvm::MDNode::get(
Load->getContext(), llvm::ConstantAsMetadata::get(Builder.getInt32(1)));
Load->setMetadata(CGM.getModule().getMDKindID("nontemporal"), Node);
}
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
if (TBAAInfo) {
llvm::MDNode *TBAAPath = CGM.getTBAAStructTagInfo(TBAABaseType, TBAAInfo,
TBAAOffset);
TBAA: use the same format for scalar TBAA and struct-path aware TBAA. An updated version of r191586 with bug fix. Struct-path aware TBAA generates tags to specify the access path, while scalar TBAA only generates tags to scalar types. We should not generate a TBAA tag with null being the first field. When a TBAA type node is null, the tag should be null too. Make sure we don't decorate an instruction with a null TBAA tag. Added a testing case for the bug reported by Richard with -relaxed-aliasing and -fsanitizer=thread. llvm-svn: 192145
2013-10-08 08:08:49 +08:00
if (TBAAPath)
CGM.DecorateInstruction(Load, TBAAPath, false/*ConvertTypeToTag*/);
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
}
Add util Emit{LoadOf,StoreTo}Scalar methods to encapsulate conversion from LLVM memory type to/from LLVM temporary type. - No intended functionality change. llvm-svn: 64191
2009-02-10 08:57:50 +08:00
Propagate SanitizerKind into CodeGenFunction::EmitCheck() call. Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
2014-11-11 06:27:30 +08:00
bool NeedsBoolCheck =
SanOpts.has(SanitizerKind::Bool) && hasBooleanRepresentation(Ty);
bool NeedsEnumCheck =
SanOpts.has(SanitizerKind::Enum) && Ty->getAs<EnumType>();
if (NeedsBoolCheck || NeedsEnumCheck) {
[UBSan] Add !nosanitize metadata to the code generated by UBSan. This is used to mark the instructions emitted by Clang to implement variety of UBSan checks. Generally, we don't want to instrument these instructions with another sanitizers (like ASan). Reviewed in http://reviews.llvm.org/D4544 llvm-svn: 213291
2014-07-18 02:46:27 +08:00
SanitizerScope SanScope(this);
ubsan: Add -fsanitize=bool and -fsanitize=enum, which check for loads of bit-patterns which are not valid values for enumerated or boolean types. These checks are the ubsan analogue of !range metadata. llvm-svn: 170108
2012-12-13 15:11:50 +08:00
llvm::APInt Min, End;
if (getRangeForType(*this, Ty, Min, End, true)) {
--End;
llvm::Value *Check;
if (!Min)
Check = Builder.CreateICmpULE(
Load, llvm::ConstantInt::get(getLLVMContext(), End));
else {
llvm::Value *Upper = Builder.CreateICmpSLE(
Load, llvm::ConstantInt::get(getLLVMContext(), End));
llvm::Value *Lower = Builder.CreateICmpSGE(
Load, llvm::ConstantInt::get(getLLVMContext(), Min));
Check = Builder.CreateAnd(Upper, Lower);
}
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
llvm::Constant *StaticArgs[] = {
EmitCheckSourceLocation(Loc),
EmitCheckTypeDescriptor(Ty)
};
Unify sanitizer kind representation between the driver and the rest of the compiler. No functional change. Differential Revision: http://reviews.llvm.org/D9618 llvm-svn: 237055
2015-05-12 05:39:14 +08:00
SanitizerMask Kind = NeedsEnumCheck ? SanitizerKind::Enum : SanitizerKind::Bool;
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
EmitCheck(std::make_pair(Check, Kind), "load_invalid_value", StaticArgs,
EmitCheckValue(Load));
ubsan: Add -fsanitize=bool and -fsanitize=enum, which check for loads of bit-patterns which are not valid values for enumerated or boolean types. These checks are the ubsan analogue of !range metadata. llvm-svn: 170108
2012-12-13 15:11:50 +08:00
}
} else if (CGM.getCodeGenOpts().OptimizationLevel > 0)
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
if (llvm::MDNode *RangeInfo = getRangeForLoadFromType(Ty))
Load->setMetadata(llvm::LLVMContext::MD_range, RangeInfo);
Implement C++0x scoped enumerations, from Daniel Wallin! (and tweaked a bit by me). llvm-svn: 116122
2010-10-09 07:50:27 +08:00
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
return EmitFromMemory(Load, Ty);
Revert r153360 (and r153380), "Second part of PR12251. Produce the range metadata in clang for booleans and". For i686 targets (eg. cygwin), I saw "Range must not be empty!" in verifier. It produces (i32)[0x80000000:0x80000000) from (uint64_t)[0xFFFFFFFF80000000ULL:0x0000000080000000ULL), for signed i32 on MDNode::Range. llvm-svn: 153382
2012-03-24 22:43:42 +08:00
}
Restore r117403 (fixing IR gen for bool atomics), this time being less aggressive about the form we expect bools to be in. I don't really have time to fix all the sources right now. llvm-svn: 117486
2010-10-28 04:58:56 +08:00
llvm::Value *CodeGenFunction::EmitToMemory(llvm::Value *Value, QualType Ty) {
// Bool has a different representation in memory than in registers.
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
if (hasBooleanRepresentation(Ty)) {
Restore r117403 (fixing IR gen for bool atomics), this time being less aggressive about the form we expect bools to be in. I don't really have time to fix all the sources right now. llvm-svn: 117486
2010-10-28 04:58:56 +08:00
// This should really always be an i1, but sometimes it's already
// an i8, and it's awkward to track those cases down.
if (Value->getType()->isIntegerTy(1))
Fix IR generation for bool on PPC (and any other target where bool is not 8 bits in memory). PR11777. llvm-svn: 167802
2012-11-13 10:05:15 +08:00
return Builder.CreateZExt(Value, ConvertTypeForMem(Ty), "frombool");
assert(Value->getType()->isIntegerTy(getContext().getTypeSize(Ty)) &&
"wrong value rep of bool");
Restore r117403 (fixing IR gen for bool atomics), this time being less aggressive about the form we expect bools to be in. I don't really have time to fix all the sources right now. llvm-svn: 117486
2010-10-28 04:58:56 +08:00
}
Revert r117403 as it caused PR8480. llvm-svn: 117456
2010-10-28 01:13:49 +08:00
Restore r117403 (fixing IR gen for bool atomics), this time being less aggressive about the form we expect bools to be in. I don't really have time to fix all the sources right now. llvm-svn: 117486
2010-10-28 04:58:56 +08:00
return Value;
}
llvm::Value *CodeGenFunction::EmitFromMemory(llvm::Value *Value, QualType Ty) {
// Bool has a different representation in memory than in registers.
Add back r153360 with a fix for enums that cover all the 32 bit values. Thanks to NAKAMURA Takumi for finding it! llvm-svn: 153383
2012-03-25 00:50:34 +08:00
if (hasBooleanRepresentation(Ty)) {
Fix IR generation for bool on PPC (and any other target where bool is not 8 bits in memory). PR11777. llvm-svn: 167802
2012-11-13 10:05:15 +08:00
assert(Value->getType()->isIntegerTy(getContext().getTypeSize(Ty)) &&
"wrong value rep of bool");
Restore r117403 (fixing IR gen for bool atomics), this time being less aggressive about the form we expect bools to be in. I don't really have time to fix all the sources right now. llvm-svn: 117486
2010-10-28 04:58:56 +08:00
return Builder.CreateTrunc(Value, Builder.getInt1Ty(), "tobool");
Revert r117403 as it caused PR8480. llvm-svn: 117456
2010-10-28 01:13:49 +08:00
}
Restore r117403 (fixing IR gen for bool atomics), this time being less aggressive about the form we expect bools to be in. I don't really have time to fix all the sources right now. llvm-svn: 117486
2010-10-28 04:58:56 +08:00
return Value;
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
void CodeGenFunction::EmitStoreOfScalar(llvm::Value *Value, Address Addr,
bool Volatile, QualType Ty,
AlignmentSource AlignSource,
llvm::MDNode *TBAAInfo,
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
bool isInit, QualType TBAABaseType,
Introduce __builtin_nontemporal_store and __builtin_nontemporal_load. Summary: Currently clang provides no general way to generate nontemporal loads/stores. There are some architecture specific builtins for doing so (e.g. in x86), but there is no way to generate non-temporal store on, e.g. AArch64. This patch adds generic builtins which are expanded to a simple store with '!nontemporal' attribute in IR. Differential Revision: http://reviews.llvm.org/D12313 llvm-svn: 247104
2015-09-09 07:52:33 +08:00
uint64_t TBAAOffset,
bool isNontemporal) {
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
// Handle vectors differently to get better performance.
if (Ty->isVectorType()) {
llvm::Type *SrcTy = Value->getType();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *VecTy = cast<llvm::VectorType>(SrcTy);
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
// Handle vec3 special.
if (VecTy->getNumElements() == 3) {
// Our source is a vec3, do a shuffle vector to make it a vec4.
[CodeGen] Simplify creation of shuffle masks. No functional change intended. llvm-svn: 243439
2015-07-29 00:25:32 +08:00
llvm::Constant *Mask[] = {Builder.getInt32(0), Builder.getInt32(1),
Builder.getInt32(2),
llvm::UndefValue::get(Builder.getInt32Ty())};
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
llvm::Value *MaskV = llvm::ConstantVector::get(Mask);
Value = Builder.CreateShuffleVector(Value,
llvm::UndefValue::get(VecTy),
MaskV, "extractVec");
SrcTy = llvm::VectorType::get(VecTy->getElementType(), 4);
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
if (Addr.getElementType() != SrcTy) {
Addr = Builder.CreateElementBitCast(Addr, SrcTy, "storetmp");
Convert loads and stores of vec3 to vec4 to achieve better code generation. Add test case. llvm-svn: 162002
2012-08-16 08:10:13 +08:00
}
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Restore r117403 (fixing IR gen for bool atomics), this time being less aggressive about the form we expect bools to be in. I don't really have time to fix all the sources right now. llvm-svn: 117486
2010-10-28 04:58:56 +08:00
Value = EmitToMemory(Value, Ty);
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
Revert "Revert r229082 for a bit, it caused PR22577." This reverts commit r229123. It was a red herring, the bug was present without r229082. llvm-svn: 229205
2015-02-14 09:35:12 +08:00
if (Ty->isAtomicType() ||
(!isInit && typeIsSuitableForInlineAtomic(Ty, Volatile))) {
Promote atomic type sizes up to a power of two, capped by MaxAtomicPromoteWidth. Fix a ton of terrible bugs with _Atomic types and (non-intrinsic-mediated) loads and stores thereto. llvm-svn: 176658
2013-03-08 05:37:17 +08:00
EmitAtomicStore(RValue::get(Value),
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue::MakeAddr(Addr, Ty, getContext(),
AlignSource, TBAAInfo),
Promote atomic type sizes up to a power of two, capped by MaxAtomicPromoteWidth. Fix a ton of terrible bugs with _Atomic types and (non-intrinsic-mediated) loads and stores thereto. llvm-svn: 176658
2013-03-08 05:37:17 +08:00
isInit);
return;
}
IRgen: Change Emit{Load,Store}OfScalar to take a required Alignment argument and update callers as best I can. - This is a work in progress, our alignment handling is very horrible / sketchy -- I am just aiming for monotonic improvement. - Serious review appreciated. llvm-svn: 111707
2010-08-21 10:24:36 +08:00
llvm::StoreInst *Store = Builder.CreateStore(Value, Addr, Volatile);
Introduce __builtin_nontemporal_store and __builtin_nontemporal_load. Summary: Currently clang provides no general way to generate nontemporal loads/stores. There are some architecture specific builtins for doing so (e.g. in x86), but there is no way to generate non-temporal store on, e.g. AArch64. This patch adds generic builtins which are expanded to a simple store with '!nontemporal' attribute in IR. Differential Revision: http://reviews.llvm.org/D12313 llvm-svn: 247104
2015-09-09 07:52:33 +08:00
if (isNontemporal) {
llvm::MDNode *Node =
llvm::MDNode::get(Store->getContext(),
llvm::ConstantAsMetadata::get(Builder.getInt32(1)));
Store->setMetadata(CGM.getModule().getMDKindID("nontemporal"), Node);
}
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
if (TBAAInfo) {
llvm::MDNode *TBAAPath = CGM.getTBAAStructTagInfo(TBAABaseType, TBAAInfo,
TBAAOffset);
TBAA: use the same format for scalar TBAA and struct-path aware TBAA. An updated version of r191586 with bug fix. Struct-path aware TBAA generates tags to specify the access path, while scalar TBAA only generates tags to scalar types. We should not generate a TBAA tag with null being the first field. When a TBAA type node is null, the tag should be null too. Make sure we don't decorate an instruction with a null TBAA tag. Added a testing case for the bug reported by Richard with -relaxed-aliasing and -fsanitizer=thread. llvm-svn: 192145
2013-10-08 08:08:49 +08:00
if (TBAAPath)
CGM.DecorateInstruction(Store, TBAAPath, false/*ConvertTypeToTag*/);
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
}
Add util Emit{LoadOf,StoreTo}Scalar methods to encapsulate conversion from LLVM memory type to/from LLVM temporary type. - No intended functionality change. llvm-svn: 64191
2009-02-10 08:57:50 +08:00
}
Some improvements to the handling of C11 atomic types: - Add atomic-to/from-nonatomic cast types - Emit atomic operations for arithmetic on atomic types - Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load - Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function. - Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it. Still to do: - Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg. - Add a signal fence builtin - Properly set the fenv state in atomic operations on floating point values - Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context) - Fix the many remaining corner cases llvm-svn: 148242
2012-01-17 01:27:18 +08:00
void CodeGenFunction::EmitStoreOfScalar(llvm::Value *value, LValue lvalue,
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
bool isInit) {
Restore correct use of GC barriers. llvm-svn: 133144
2011-06-16 12:16:24 +08:00
EmitStoreOfScalar(value, lvalue.getAddress(), lvalue.isVolatile(),
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
lvalue.getType(), lvalue.getAlignmentSource(),
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
lvalue.getTBAAInfo(), isInit, lvalue.getTBAABaseType(),
Introduce __builtin_nontemporal_store and __builtin_nontemporal_load. Summary: Currently clang provides no general way to generate nontemporal loads/stores. There are some architecture specific builtins for doing so (e.g. in x86), but there is no way to generate non-temporal store on, e.g. AArch64. This patch adds generic builtins which are expanded to a simple store with '!nontemporal' attribute in IR. Differential Revision: http://reviews.llvm.org/D12313 llvm-svn: 247104
2015-09-09 07:52:33 +08:00
lvalue.getTBAAOffset(), lvalue.isNontemporal());
Restore correct use of GC barriers. llvm-svn: 133144
2011-06-16 12:16:24 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
/// EmitLoadOfLValue - Given an expression that represents a value lvalue, this
/// method emits the address of the lvalue, then loads the result as an rvalue,
/// returning the rvalue.
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
RValue CodeGenFunction::EmitLoadOfLValue(LValue LV, SourceLocation Loc) {
Few more changes due to Daniel's feedback. llvm-svn: 59645
2008-11-20 01:34:06 +08:00
if (LV.isObjCWeak()) {
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
// load of a __weak object.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address AddrWeakObj = LV.getAddress();
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
return RValue::get(CGM.getObjCRuntime().EmitObjCWeakRead(*this,
AddrWeakObj));
Generate objc_read_weak for __weak objc loads. llvm-svn: 59553
2008-11-19 05:45:40 +08:00
}
objective-C arc: load of a __weak object happens via call to objc_loadWeak. This retains and autorelease the weakly-refereced object. This hidden autorelease sometimes makes __weak variable alive even after the weak reference is erased, because the object is still referenced by an autorelease pool. This patch overcomes this behavior by loading a weak object via call to objc_loadWeakRetained(), followng it by objc_release at appropriate place, thereby removing the hidden autorelease. // rdar://10849570 llvm-svn: 168740
2012-11-28 07:02:53 +08:00
if (LV.getQuals().getObjCLifetime() == Qualifiers::OCL_Weak) {
llvm::Value *Object = EmitARCLoadWeakRetained(LV.getAddress());
Object = EmitObjCConsumeObject(LV.getType(), Object);
return RValue::get(Object);
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Add support for codegen'ing vector subscripts, at least when they are lvalues. llvm-svn: 39724
2007-07-11 05:17:59 +08:00
if (LV.isSimple()) {
Fix PR10204 in a better way. llvm-svn: 133943
2011-06-28 05:24:11 +08:00
assert(!LV.getType()->isFunctionType());
Experiment with using first-class aggregates to represent member function pointers. I find the resulting code to be substantially cleaner, and it makes it very easy to use the same APIs for data member pointers (which I have conscientiously avoided here), and it avoids a plethora of potential inefficiencies due to excessive memory copying, but we'll have to see if it actually works. llvm-svn: 111776
2010-08-22 18:59:02 +08:00
// Everything needs a load.
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
return RValue::get(EmitLoadOfScalar(LV, Loc));
Add support for codegen'ing vector subscripts, at least when they are lvalues. llvm-svn: 39724
2007-07-11 05:17:59 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Add support for codegen'ing vector subscripts, at least when they are lvalues. llvm-svn: 39724
2007-07-11 05:17:59 +08:00
if (LV.isVectorElt()) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::LoadInst *Load = Builder.CreateLoad(LV.getVectorAddress(),
Make sure we correctly set the alignment for vector loads and stores associated with vector element lvalues. Patch by Kevin Schoedel (with some minor modifications by me). llvm-svn: 153285
2012-03-23 06:36:39 +08:00
LV.isVolatileQualified());
return RValue::get(Builder.CreateExtractElement(Load, LV.getVectorIdx(),
Add support for codegen'ing vector subscripts, at least when they are lvalues. llvm-svn: 39724
2007-07-11 05:17:59 +08:00
"vecext"));
}
implement lvalue to rvalue conversion for ocuvector components. We can now compile stuff like this: typedef __attribute__(( ocu_vector_type(4) )) float float4; float4 test1(float4 V) { return V.wzyx+V; } to: _test1: pshufd $27, %xmm0, %xmm1 addps %xmm0, %xmm1 movaps %xmm1, %xmm0 ret and: _test1: mfspr r2, 256 oris r3, r2, 4096 mtspr 256, r3 li r3, lo16(LCPI1_0) lis r4, ha16(LCPI1_0) lvx v3, r4, r3 vperm v3, v2, v2, v3 vaddfp v2, v3, v2 mtspr 256, r2 blr llvm-svn: 40771
2007-08-03 08:16:29 +08:00
// If this is a reference to a subset of the elements of a vector, either
// shuffle the input or extract/insert them as appropriate.
OCUVector -> ExtVector, shorthand for extended vector, per feedback from Chris. llvm-svn: 49942
2008-04-19 07:10:10 +08:00
if (LV.isExtVectorElt())
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
return EmitLoadOfExtVectorElementLValue(LV);
Implement bitfield read. llvm-svn: 46257
2008-01-23 04:17:04 +08:00
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
// Global Register variables always invoke intrinsics
if (LV.isGlobalReg())
return EmitLoadOfGlobalRegLValue(LV);
Rip the ObjCPropertyRef l-value kind out of IR-generation. llvm-svn: 143908
2011-11-07 11:59:57 +08:00
assert(LV.isBitField() && "Unknown LValue type!");
return EmitLoadOfBitfieldLValue(LV);
refactor handling of ocuvector lvalue->rvalue codegen into its own method. llvm-svn: 40780
2007-08-04 00:18:34 +08:00
}
Add support for scalar-returning element accesses like V.x llvm-svn: 40777
2007-08-03 23:52:31 +08:00
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
RValue CodeGenFunction::EmitLoadOfBitfieldLValue(LValue LV) {
IRgen: Move BitFieldIsSigned bit into CGBitFieldInfo. llvm-svn: 100513
2010-04-06 09:07:44 +08:00
const CGBitFieldInfo &Info = LV.getBitFieldInfo();
Implement bitfield read. llvm-svn: 46257
2008-01-23 04:17:04 +08:00
IRgen: Move EmitLoadOfBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself. - This lets the method focus slightly more on emitting clean IR to honor the policy which has been selected. On 403.gcc's combine.c, x86_64, -O0, this reduces the number of lines in the .ll file (~= # of instructions) by 2.5%. - No intended functionality change -- at -O3 this should produce equivalent if not identical output. On 403.gcc's combine.c, x86_64, -O3, this isn't quite true and some of the changes are regressions, but I'm not going to worry about that until we move to a new access policy. - There is still some room for improvement in the generated IR, in particular we can usually fold the sign-extension of the bit-field into one of the component access. See the FIXME. llvm-svn: 101192
2010-04-14 07:34:15 +08:00
// Get the output type.
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type *ResLTy = ConvertType(LV.getType());
IRgen: Move EmitLoadOfBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself. - This lets the method focus slightly more on emitting clean IR to honor the policy which has been selected. On 403.gcc's combine.c, x86_64, -O0, this reduces the number of lines in the .ll file (~= # of instructions) by 2.5%. - No intended functionality change -- at -O3 this should produce equivalent if not identical output. On 403.gcc's combine.c, x86_64, -O3, this isn't quite true and some of the changes are regressions, but I'm not going to worry about that until we move to a new access policy. - There is still some room for improvement in the generated IR, in particular we can usually fold the sign-extension of the bit-field into one of the component access. See the FIXME. llvm-svn: 101192
2010-04-14 07:34:15 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Ptr = LV.getBitFieldAddress();
llvm::Value *Val = Builder.CreateLoad(Ptr, LV.isVolatileQualified(), "bf.load");
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
if (Info.IsSigned) {
Avoid unsigned Compare to int Cast arithmetic results to avoid comparison of an unsigned to an int. llvm-svn: 172570
2013-01-16 07:13:47 +08:00
assert(static_cast<unsigned>(Info.Offset + Info.Size) <= Info.StorageSize);
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
unsigned HighBits = Info.StorageSize - Info.Offset - Info.Size;
if (HighBits)
Val = Builder.CreateShl(Val, HighBits, "bf.shl");
if (Info.Offset + HighBits)
Val = Builder.CreateAShr(Val, Info.Offset + HighBits, "bf.ashr");
} else {
if (Info.Offset)
Val = Builder.CreateLShr(Val, Info.Offset, "bf.lshr");
Similar to 170440 - fix build warning with gcc llvm-svn: 170461
2012-12-19 06:22:16 +08:00
if (static_cast<unsigned>(Info.Offset) + Info.Size < Info.StorageSize)
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
Val = Builder.CreateAnd(Val, llvm::APInt::getLowBitsSet(Info.StorageSize,
Info.Size),
"bf.clear");
IRgen: Move EmitLoadOfBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself. - This lets the method focus slightly more on emitting clean IR to honor the policy which has been selected. On 403.gcc's combine.c, x86_64, -O0, this reduces the number of lines in the .ll file (~= # of instructions) by 2.5%. - No intended functionality change -- at -O3 this should produce equivalent if not identical output. On 403.gcc's combine.c, x86_64, -O3, this isn't quite true and some of the changes are regressions, but I'm not going to worry about that until we move to a new access policy. - There is still some room for improvement in the generated IR, in particular we can usually fold the sign-extension of the bit-field into one of the component access. See the FIXME. llvm-svn: 101192
2010-04-14 07:34:15 +08:00
}
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
Val = Builder.CreateIntCast(Val, ResLTy, Info.IsSigned, "bf.cast");
Fix support for _Bool bitfields. The issue is that the bitfield width used for _Bool is not the same as the primitive width (which for _Bool is 1 bit). The load and store changes add some casts to make the types consistent. The EmitLValue changes make sure that the pointer is of an appropriate type for loading the bitfield. This isn't perfect, but it's an improvement, and getting everything right depends on actually laying out structs in an ABI-compliant way. llvm-svn: 51224
2008-05-18 04:03:47 +08:00
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
return RValue::get(Val);
Implement bitfield read. llvm-svn: 46257
2008-01-23 04:17:04 +08:00
}
Vector codegen improvements llvm-svn: 62458
2009-01-18 14:42:49 +08:00
// If this is a reference to a subset of the elements of a vector, create an
// appropriate shufflevector.
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
RValue CodeGenFunction::EmitLoadOfExtVectorElementLValue(LValue LV) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *Vec = Builder.CreateLoad(LV.getExtVectorAddress(),
LV.isVolatileQualified());
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Extend vector member references to include {.hi, .lo, .e, .o} which return a vector of the same element type and half the width, with the high, low, even, and odd elements respectively. Allow member references to member references, so that .hi.hi gives you the high quarter of a vector. This is fairly convenient syntax for some insert/extract operations. Remove some unnecessary methods/types in the ExtVectorElementExpr class. llvm-svn: 50892
2008-05-09 14:41:27 +08:00
const llvm::Constant *Elts = LV.getExtVectorElts();
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
// If the result of the expression is a non-vector type, we must be extracting
// a single element. Just codegen as an extractelement.
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
const VectorType *ExprVT = LV.getType()->getAs<VectorType>();
fix a codegen bug handling ocuvector element exprs. llvm-svn: 40995
2007-08-11 01:10:08 +08:00
if (!ExprVT) {
Move getAccessedFieldNo out of lib/AST/Expr.cpp into lib/CodeGen/CGExpr.cpp and to change include/clang/AST/Attr.h to use its own enum for visibility types instead of using llvm::GlobalValue::VisibilityTypes. These changes eliminate dependencies in the AST library on LLVM's VMCore library. llvm-svn: 51398
2008-05-22 08:50:06 +08:00
unsigned InIdx = getAccessedFieldNo(0, Elts);
[CodeGen] Don't cast and use SizeTy instead of Int32Ty when constructing {extract,insert} vector element instructions. llvm-svn: 209942
2014-05-31 08:22:12 +08:00
llvm::Value *Elt = llvm::ConstantInt::get(SizeTy, InIdx);
de-tmpify clang. llvm-svn: 140637
2011-09-28 05:06:10 +08:00
return RValue::get(Builder.CreateExtractElement(Vec, Elt));
refactor handling of ocuvector lvalue->rvalue codegen into its own method. llvm-svn: 40780
2007-08-04 00:18:34 +08:00
}
Vector codegen improvements llvm-svn: 62458
2009-01-18 14:42:49 +08:00
// Always use shuffle vector to try to retain the original program structure
fix a codegen bug handling ocuvector element exprs. llvm-svn: 40995
2007-08-11 01:10:08 +08:00
unsigned NumResultElts = ExprVT->getNumElements();
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<llvm::Constant*, 4> Mask;
reapply r148902: "use the new ConstantVector::getSplat method where it makes sense." Also simplify a bunch of code to use the Builder->getInt32 instead of doing it the hard and ugly way. Much more progress could be made here, but I don't plan to do it. llvm-svn: 148926
2012-01-25 13:34:41 +08:00
for (unsigned i = 0; i != NumResultElts; ++i)
Mask.push_back(Builder.getInt32(getAccessedFieldNo(i, Elts)));
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
update for ConstantVector API change. llvm-svn: 125538
2011-02-15 08:14:06 +08:00
llvm::Value *MaskV = llvm::ConstantVector::get(Mask);
Vec = Builder.CreateShuffleVector(Vec, llvm::UndefValue::get(Vec->getType()),
de-tmpify clang. llvm-svn: 140637
2011-09-28 05:06:10 +08:00
MaskV);
Vector codegen improvements llvm-svn: 62458
2009-01-18 14:42:49 +08:00
return RValue::get(Vec);
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
}
ext_vector IRGen. Patch to allow indexing into ext_vector_type's 'hi/lo' components when used as lvalue. rdar://18031917 pr20697 llvm-svn: 215991
2014-08-20 01:17:40 +08:00
/// @brief Generates lvalue for partial ext_vector access.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address CodeGenFunction::EmitExtVectorElementLValue(LValue LV) {
Address VectorAddress = LV.getExtVectorAddress();
ext_vector IRGen. Patch to allow indexing into ext_vector_type's 'hi/lo' components when used as lvalue. rdar://18031917 pr20697 llvm-svn: 215991
2014-08-20 01:17:40 +08:00
const VectorType *ExprVT = LV.getType()->getAs<VectorType>();
QualType EQT = ExprVT->getElementType();
llvm::Type *VectorElementTy = CGM.getTypes().ConvertType(EQT);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address CastToPointerElement =
Builder.CreateElementBitCast(VectorAddress, VectorElementTy,
"conv.ptr.element");
ext_vector IRGen. Patch to allow indexing into ext_vector_type's 'hi/lo' components when used as lvalue. rdar://18031917 pr20697 llvm-svn: 215991
2014-08-20 01:17:40 +08:00
const llvm::Constant *Elts = LV.getExtVectorElts();
unsigned ix = getAccessedFieldNo(0, Elts);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address VectorBasePtrPlusIx =
Builder.CreateConstInBoundsGEP(CastToPointerElement, ix,
getContext().getTypeSizeInChars(EQT),
"vector.elt");
ext_vector IRGen. Patch to allow indexing into ext_vector_type's 'hi/lo' components when used as lvalue. rdar://18031917 pr20697 llvm-svn: 215991
2014-08-20 01:17:40 +08:00
return VectorBasePtrPlusIx;
}
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
/// @brief Load of global gamed gegisters are always calls to intrinsics.
RValue CodeGenFunction::EmitLoadOfGlobalRegLValue(LValue LV) {
Add pointer types to global named register This patch adds support for pointer types in global named registers variables. It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls. Also adds some early checks on types on SemaDecl to avoid the assert. Tests changed accordingly. (PR19837) llvm-svn: 210274
2014-06-06 00:45:22 +08:00
assert((LV.getType()->isIntegerType() || LV.getType()->isPointerType()) &&
"Bad type for register variable");
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
llvm::MDNode *RegName = cast<llvm::MDNode>(
cast<llvm::MetadataAsValue>(LV.getGlobalReg())->getMetadata());
Add pointer types to global named register This patch adds support for pointer types in global named registers variables. It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls. Also adds some early checks on types on SemaDecl to avoid the assert. Tests changed accordingly. (PR19837) llvm-svn: 210274
2014-06-06 00:45:22 +08:00
// We accept integer and pointer types only
llvm::Type *OrigTy = CGM.getTypes().ConvertType(LV.getType());
llvm::Type *Ty = OrigTy;
if (OrigTy->isPointerTy())
Ty = CGM.getTypes().getDataLayout().getIntPtrType(OrigTy);
llvm::Type *Types[] = { Ty };
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
llvm::Value *F = CGM.getIntrinsic(llvm::Intrinsic::read_register, Types);
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
llvm::Value *Call = Builder.CreateCall(
F, llvm::MetadataAsValue::get(Ty->getContext(), RegName));
Add pointer types to global named register This patch adds support for pointer types in global named registers variables. It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls. Also adds some early checks on types on SemaDecl to avoid the assert. Tests changed accordingly. (PR19837) llvm-svn: 210274
2014-06-06 00:45:22 +08:00
if (OrigTy->isPointerTy())
Call = Builder.CreateIntToPtr(Call, OrigTy);
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
return RValue::get(Call);
}
refactor handling of ocuvector lvalue->rvalue codegen into its own method. llvm-svn: 40780
2007-08-04 00:18:34 +08:00
Rename ArithAssignBinaryOperator -> CompoundAssignOperator, implement codegen support for +=. llvm-svn: 39710
2007-06-30 00:31:29 +08:00
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
/// EmitStoreThroughLValue - Store the specified rvalue into the specified
/// lvalue, where both are guaranteed to the have the same type, and that type
/// is 'Ty'.
No functionality change. Reflow lines that could fit on one line. Break lines that had 80-column violations. Remove spurious emacs mode markers on .cpp files. llvm-svn: 191797
2013-10-02 05:51:38 +08:00
void CodeGenFunction::EmitStoreThroughLValue(RValue Src, LValue Dst,
Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits). Several pieces of code were relying on implicit debug location setting which usually lead to incorrect line information anyway. So I've fixed those (in r225955 and r225845) separately which should pave the way for this commit to be cleanly reapplied. The reason these implicit dependencies resulted in crashes with this patch is that the debug location would no longer implicitly leak from one place to another, but be set back to invalid. Once a call with no/invalid location was emitted, if that call was ever inlined it could produce invalid debugloc chains and assert during LLVM's codegen. There may be further cases of such bugs in this patch - they're hard to flush out with regression testing, so I'll keep an eye out for reports and investigate/fix them ASAP if they come up. Original commit message: Reapply "DebugInfo: Generalize debug info location handling" Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Recommitted in r224941 and reverted in r224970 after it caused a crash when building compiler-rt. Looks to be due to this change zeroing out the debug location when emitting default arguments (which were meant to inherit their outer expression's location) thus creating call instructions without locations - these create problems for inlining and must not be created. That is fixed and tested in this version of the change. Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 225956
2015-01-14 15:38:27 +08:00
bool isInit) {
add codegen support for storing into a single-element ocu lvalue, such as: vec2.x = f; llvm-svn: 40781
2007-08-04 00:28:33 +08:00
if (!Dst.isSimple()) {
if (Dst.isVectorElt()) {
// Read/modify/write the vector, inserting the new element.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *Vec = Builder.CreateLoad(Dst.getVectorAddress(),
Dst.isVolatileQualified());
Generalize RValue to handle complex better, generalize EmitCompoundStmt to support any sort of expr, add a new EmitAnyExpr routine. llvm-svn: 41660
2007-09-01 06:49:20 +08:00
Vec = Builder.CreateInsertElement(Vec, Src.getScalarVal(),
add codegen support for storing into a single-element ocu lvalue, such as: vec2.x = f; llvm-svn: 40781
2007-08-04 00:28:33 +08:00
Dst.getVectorIdx(), "vecins");
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Builder.CreateStore(Vec, Dst.getVectorAddress(),
Dst.isVolatileQualified());
add codegen support for storing into a single-element ocu lvalue, such as: vec2.x = f; llvm-svn: 40781
2007-08-04 00:28:33 +08:00
return;
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
OCUVector -> ExtVector, shorthand for extended vector, per feedback from Chris. llvm-svn: 49942
2008-04-19 07:10:10 +08:00
// If this is an update of extended vector elements, insert them as
// appropriate.
if (Dst.isExtVectorElt())
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
return EmitStoreThroughExtVectorComponentLValue(Src, Dst);
Implement bitfield write. llvm-svn: 46258
2008-01-23 06:36:45 +08:00
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
if (Dst.isGlobalReg())
return EmitStoreThroughGlobalRegLValue(Src, Dst);
Rip the ObjCPropertyRef l-value kind out of IR-generation. llvm-svn: 143908
2011-11-07 11:59:57 +08:00
assert(Dst.isBitField() && "Unknown LValue type");
return EmitStoreThroughBitfieldLValue(Src, Dst);
add codegen support for storing into a single-element ocu lvalue, such as: vec2.x = f; llvm-svn: 40781
2007-08-04 00:28:33 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
// There's special magic for assigning into an ARC-qualified l-value.
if (Qualifiers::ObjCLifetime Lifetime = Dst.getQuals().getObjCLifetime()) {
switch (Lifetime) {
case Qualifiers::OCL_None:
llvm_unreachable("present but none");
case Qualifiers::OCL_ExplicitNone:
// nothing special
break;
case Qualifiers::OCL_Strong:
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
EmitARCStoreStrong(Dst, Src.getScalarVal(), /*ignore*/ true);
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
return;
case Qualifiers::OCL_Weak:
EmitARCStoreWeak(Dst.getAddress(), Src.getScalarVal(), /*ignore*/ true);
return;
case Qualifiers::OCL_Autoreleasing:
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
Src = RValue::get(EmitObjCExtendObjectLifetime(Dst.getType(),
Src.getScalarVal()));
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
// fall into the normal path
break;
}
}
Handle case of none gc'able objects regardless of their type. llvm-svn: 65205
2009-02-21 08:30:43 +08:00
if (Dst.isObjCWeak() && !Dst.isNonGC()) {
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
// load of a __weak object.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address LvalueDst = Dst.getAddress();
Few more changes due to Daniel's feedback. llvm-svn: 59645
2008-11-20 01:34:06 +08:00
llvm::Value *src = Src.getScalarVal();
Fixup CodeGen for __weak __block variables. Radar 6756266 llvm-svn: 69010
2009-04-14 08:57:29 +08:00
CGM.getObjCRuntime().EmitObjCWeakAssign(*this, src, LvalueDst);
Few more changes due to Daniel's feedback. llvm-svn: 59645
2008-11-20 01:34:06 +08:00
return;
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Handle case of none gc'able objects regardless of their type. llvm-svn: 65205
2009-02-21 08:30:43 +08:00
if (Dst.isObjCStrong() && !Dst.isNonGC()) {
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
// load of a __strong object.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address LvalueDst = Dst.getAddress();
Few more changes due to Daniel's feedback. llvm-svn: 59645
2008-11-20 01:34:06 +08:00
llvm::Value *src = Src.getScalarVal();
Patch fixes a code gen. bug in generation of objc_assign_ivar (objc GC's API). llvm-svn: 82724
2009-09-25 06:25:38 +08:00
if (Dst.isObjCIvar()) {
assert(Dst.getBaseIvarExp() && "BaseIvarExp is NULL");
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Type *ResultType = IntPtrTy;
Address dst = EmitPointerWithAlignment(Dst.getBaseIvarExp());
llvm::Value *RHS = dst.getPointer();
Patch fixes a code gen. bug in generation of objc_assign_ivar (objc GC's API). llvm-svn: 82724
2009-09-25 06:25:38 +08:00
RHS = Builder.CreatePtrToInt(RHS, ResultType, "sub.ptr.rhs.cast");
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
llvm::Value *LHS =
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Builder.CreatePtrToInt(LvalueDst.getPointer(), ResultType,
"sub.ptr.lhs.cast");
Patch fixes a code gen. bug in generation of objc_assign_ivar (objc GC's API). llvm-svn: 82724
2009-09-25 06:25:38 +08:00
llvm::Value *BytesBetween = Builder.CreateSub(LHS, RHS, "ivar.offset");
Fixed another code gen bug in objc's new write-barrier API. llvm-svn: 82735
2009-09-25 08:00:20 +08:00
CGM.getObjCRuntime().EmitObjCIvarAssign(*this, src, dst,
Patch fixes a code gen. bug in generation of objc_assign_ivar (objc GC's API). llvm-svn: 82724
2009-09-25 06:25:38 +08:00
BytesBetween);
Adopt objc_assign_threadlocal() for __thread variables of GC types. Implements radar 8203301. llvm-svn: 108917
2010-07-21 04:30:03 +08:00
} else if (Dst.isGlobalObjCRef()) {
CGM.getObjCRuntime().EmitObjCGlobalAssign(*this, src, LvalueDst,
Dst.isThreadLocalRef());
}
Provide basic support for generation of objc2's objc_assign_global API when assigning to global objective-c object pointer. llvm-svn: 70939
2009-05-05 07:27:20 +08:00
else
CGM.getObjCRuntime().EmitObjCStrongCastAssign(*this, src, LvalueDst);
Few more changes due to Daniel's feedback. llvm-svn: 59645
2008-11-20 01:34:06 +08:00
return;
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
start splitting out aggregate value computation from EmitExpr into EmitAggExpr. aggregate value and scalar expression computation are very different, this gets them away from each other. This causes a temporary regression on some complex number examples. llvm-svn: 41014
2007-08-11 08:04:45 +08:00
assert(Src.isScalar() && "Can't emit an agg store with this method");
Some improvements to the handling of C11 atomic types: - Add atomic-to/from-nonatomic cast types - Emit atomic operations for arithmetic on atomic types - Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load - Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function. - Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it. Still to do: - Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg. - Add a signal fence builtin - Properly set the fenv state in atomic operations on floating point values - Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context) - Fix the many remaining corner cases llvm-svn: 148242
2012-01-17 01:27:18 +08:00
EmitStoreOfScalar(Src.getScalarVal(), Dst, isInit);
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
}
Implement bitfield write. llvm-svn: 46258
2008-01-23 06:36:45 +08:00
void CodeGenFunction::EmitStoreThroughBitfieldLValue(RValue Src, LValue Dst,
Fix redundant load of bit-fields on assignment (to get the updated value). - Use extra argument to EmitStoreThroughLValue to provide place to write update bit-field value if caller requires it. - This fixes several FIXMEs. llvm-svn: 59615
2008-11-19 17:36:46 +08:00
llvm::Value **Result) {
IRgen: Move BitFieldIsSigned bit into CGBitFieldInfo. llvm-svn: 100513
2010-04-06 09:07:44 +08:00
const CGBitFieldInfo &Info = Dst.getBitFieldInfo();
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type *ResLTy = ConvertTypeForMem(Dst.getType());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Ptr = Dst.getBitFieldAddress();
Implement bitfield write. llvm-svn: 46258
2008-01-23 06:36:45 +08:00
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself. - Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job. - No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit. The new fixes from r101222 are: 1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt. 2. Swap the order of arguments to OR, to get a tad more constant folding. llvm-svn: 101339
2010-04-15 11:47:33 +08:00
// Get the source value, truncated to the width of the bit-field.
Fix redundant load of bit-fields on assignment (to get the updated value). - Use extra argument to EmitStoreThroughLValue to provide place to write update bit-field value if caller requires it. - This fixes several FIXMEs. llvm-svn: 59615
2008-11-19 17:36:46 +08:00
llvm::Value *SrcVal = Src.getScalarVal();
Fix an assert when assigning a boolean value to a bitfield of type _Bool. llvm-svn: 101678
2010-04-18 05:52:22 +08:00
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
// Cast the source to the storage type and shift it into place.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
SrcVal = Builder.CreateIntCast(SrcVal, Ptr.getElementType(),
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
/*IsSigned=*/false);
llvm::Value *MaskedVal = SrcVal;
// See if there are other bits in the bitfield's storage we'll need to load
// and mask together with source before storing.
if (Info.StorageSize != Info.Size) {
assert(Info.StorageSize > Info.Size && "Invalid bitfield size.");
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *Val =
Builder.CreateLoad(Ptr, Dst.isVolatileQualified(), "bf.load");
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
// Mask the source value as needed.
if (!hasBooleanRepresentation(Dst.getType()))
SrcVal = Builder.CreateAnd(SrcVal,
llvm::APInt::getLowBitsSet(Info.StorageSize,
Info.Size),
"bf.value");
MaskedVal = SrcVal;
if (Info.Offset)
SrcVal = Builder.CreateShl(SrcVal, Info.Offset, "bf.shl");
// Mask out the original value.
Val = Builder.CreateAnd(Val,
~llvm::APInt::getBitsSet(Info.StorageSize,
Info.Offset,
Info.Offset + Info.Size),
"bf.clear");
Fix redundant load of bit-fields on assignment (to get the updated value). - Use extra argument to EmitStoreThroughLValue to provide place to write update bit-field value if caller requires it. - This fixes several FIXMEs. llvm-svn: 59615
2008-11-19 17:36:46 +08:00
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
// Or together the unchanged values and the source value.
SrcVal = Builder.CreateOr(Val, SrcVal, "bf.set");
} else {
assert(Info.Offset == 0);
Fix redundant load of bit-fields on assignment (to get the updated value). - Use extra argument to EmitStoreThroughLValue to provide place to write update bit-field value if caller requires it. - This fixes several FIXMEs. llvm-svn: 59615
2008-11-19 17:36:46 +08:00
}
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
// Write the new value back out.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Builder.CreateStore(SrcVal, Ptr, Dst.isVolatileQualified());
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself. - Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job. - No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit. The new fixes from r101222 are: 1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt. 2. Swap the order of arguments to OR, to get a tad more constant folding. llvm-svn: 101339
2010-04-15 11:47:33 +08:00
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
// Return the new value of the bit-field, if requested.
if (Result) {
llvm::Value *ResultVal = MaskedVal;
// Sign extend the value if needed.
if (Info.IsSigned) {
assert(Info.Size <= Info.StorageSize);
unsigned HighBits = Info.StorageSize - Info.Size;
if (HighBits) {
ResultVal = Builder.CreateShl(ResultVal, HighBits, "bf.result.shl");
ResultVal = Builder.CreateAShr(ResultVal, HighBits, "bf.result.ashr");
}
IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself. - Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job. - No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit. The new fixes from r101222 are: 1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt. 2. Swap the order of arguments to OR, to get a tad more constant folding. llvm-svn: 101339
2010-04-15 11:47:33 +08:00
}
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
ResultVal = Builder.CreateIntCast(ResultVal, ResLTy, Info.IsSigned,
"bf.result.cast");
Make sure CodeGen uses a value of the correct type as the result of of assignment to a bool bitfield. PR14638. llvm-svn: 170480
2012-12-19 08:26:58 +08:00
*Result = EmitFromMemory(ResultVal, Dst.getType());
Fix bitfield accesses which straddle the boundary of the underlying type. - This generates somewhat less optimal code than before but this is not hard to rectify once stable (at the cost of slightly more complex code). - This currently always uses little-endian ordering of the bitfield. - This breaks the CodeGen/bitfield.c test because it was grepping for hard-coded assembly instructions. Will fix once a better test case is constructed (hard to do without execution). - This fixes SingleSource/UnitTests/2006-01-23-InitializedBitField.c and Regression/C/PR1386.c from the test suite. - <rdar://problem/6085090>, <rdar://problem/6094169> llvm-svn: 54395
2008-08-06 13:08:45 +08:00
}
Implement bitfield write. llvm-svn: 46258
2008-01-23 06:36:45 +08:00
}
OCUVector -> ExtVector, shorthand for extended vector, per feedback from Chris. llvm-svn: 49942
2008-04-19 07:10:10 +08:00
void CodeGenFunction::EmitStoreThroughExtVectorComponentLValue(RValue Src,
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
LValue Dst) {
add codegen support for storing into a single-element ocu lvalue, such as: vec2.x = f; llvm-svn: 40781
2007-08-04 00:28:33 +08:00
// This access turns into a read/modify/write of the vector. Load the input
// value now.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *Vec = Builder.CreateLoad(Dst.getExtVectorAddress(),
Dst.isVolatileQualified());
Extend vector member references to include {.hi, .lo, .e, .o} which return a vector of the same element type and half the width, with the high, low, even, and odd elements respectively. Allow member references to member references, so that .hi.hi gives you the high quarter of a vector. This is fairly convenient syntax for some insert/extract operations. Remove some unnecessary methods/types in the ExtVectorElementExpr class. llvm-svn: 50892
2008-05-09 14:41:27 +08:00
const llvm::Constant *Elts = Dst.getExtVectorElts();
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Generalize RValue to handle complex better, generalize EmitCompoundStmt to support any sort of expr, add a new EmitAnyExpr routine. llvm-svn: 41660
2007-09-01 06:49:20 +08:00
llvm::Value *SrcVal = Src.getScalarVal();
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
if (const VectorType *VTy = Dst.getType()->getAs<VectorType>()) {
implement codegen for multidest ocuvector expressions, like: vec2.yx = vec2; // reverse llvm-svn: 40782
2007-08-04 00:37:04 +08:00
unsigned NumSrcElts = VTy->getNumElements();
Vector codegen improvements llvm-svn: 62458
2009-01-18 14:42:49 +08:00
unsigned NumDstElts =
cast<llvm::VectorType>(Vec->getType())->getNumElements();
if (NumDstElts == NumSrcElts) {
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
// Use shuffle vector is the src and destination are the same number of
// elements and restore the vector mask since it is on the side it will be
// stored.
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<llvm::Constant*, 4> Mask(NumDstElts);
reapply r148902: "use the new ConstantVector::getSplat method where it makes sense." Also simplify a bunch of code to use the Builder->getInt32 instead of doing it the hard and ugly way. Much more progress could be made here, but I don't plan to do it. llvm-svn: 148926
2012-01-25 13:34:41 +08:00
for (unsigned i = 0; i != NumSrcElts; ++i)
Mask[getAccessedFieldNo(i, Elts)] = Builder.getInt32(i);
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
update for ConstantVector API change. llvm-svn: 125538
2011-02-15 08:14:06 +08:00
llvm::Value *MaskV = llvm::ConstantVector::get(Mask);
Vector codegen improvements llvm-svn: 62458
2009-01-18 14:42:49 +08:00
Vec = Builder.CreateShuffleVector(SrcVal,
Update for LLVM API changes. llvm-svn: 77638
2009-07-31 07:11:26 +08:00
llvm::UndefValue::get(Vec->getType()),
de-tmpify clang. llvm-svn: 140637
2011-09-28 05:06:10 +08:00
MaskV);
Canonicalize else spacing. llvm-svn: 77629
2009-07-31 06:28:39 +08:00
} else if (NumDstElts > NumSrcElts) {
Vector codegen improvements llvm-svn: 62458
2009-01-18 14:42:49 +08:00
// Extended the source vector to the same length and then shuffle it
// into the destination.
// FIXME: since we're shuffling with undef, can we just use the indices
// into that? This could be simpler.
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<llvm::Constant*, 4> ExtMask;
Use a simpler (and more efficient) pattern to pad vectors. llvm-svn: 150475
2012-02-14 20:06:21 +08:00
for (unsigned i = 0; i != NumSrcElts; ++i)
reapply r148902: "use the new ConstantVector::getSplat method where it makes sense." Also simplify a bunch of code to use the Builder->getInt32 instead of doing it the hard and ugly way. Much more progress could be made here, but I don't plan to do it. llvm-svn: 148926
2012-01-25 13:34:41 +08:00
ExtMask.push_back(Builder.getInt32(i));
Use a simpler (and more efficient) pattern to pad vectors. llvm-svn: 150475
2012-02-14 20:06:21 +08:00
ExtMask.resize(NumDstElts, llvm::UndefValue::get(Int32Ty));
update for ConstantVector API change. llvm-svn: 125538
2011-02-15 08:14:06 +08:00
llvm::Value *ExtMaskV = llvm::ConstantVector::get(ExtMask);
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
llvm::Value *ExtSrcVal =
80-cols. llvm-svn: 64779
2009-02-18 02:31:04 +08:00
Builder.CreateShuffleVector(SrcVal,
Update for LLVM API changes. llvm-svn: 77638
2009-07-31 07:11:26 +08:00
llvm::UndefValue::get(SrcVal->getType()),
de-tmpify clang. llvm-svn: 140637
2011-09-28 05:06:10 +08:00
ExtMaskV);
Vector codegen improvements llvm-svn: 62458
2009-01-18 14:42:49 +08:00
// build identity
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<llvm::Constant*, 4> Mask;
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
for (unsigned i = 0; i != NumDstElts; ++i)
reapply r148902: "use the new ConstantVector::getSplat method where it makes sense." Also simplify a bunch of code to use the Builder->getInt32 instead of doing it the hard and ugly way. Much more progress could be made here, but I don't plan to do it. llvm-svn: 148926
2012-01-25 13:34:41 +08:00
Mask.push_back(Builder.getInt32(i));
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
Fix a crash in EmitStoreThroughExtVectorComponentLValue for vectors of odd sizes. In OpenCL a vector of 3 elements, acts like a vector of four elements. So for a vector of size 3 the '.hi' and '.odd' accessors, would access the elements {2, 3} and {1, 3} respectively. However, in EmitStoreThroughExtVectorComponentLValue we are still operating on a vector of size 3, so we should only access {2} and {1}. We do this by checking the last element to be accessed, and ignore it if it is out-of-bounds. EmitLoadOfExtVectorElementLValue doesn't have a similar problem, because it does a direct shufflevector with undef, so an out-of-bounds access just gives an undef value. Patch by Anastasia Stulova! llvm-svn: 195367
2013-11-22 01:09:05 +08:00
// When the vector size is odd and .odd or .hi is used, the last element
// of the Elts constant array will be one past the size of the vector.
// Ignore the last element here, if it is greater than the mask size.
if (getAccessedFieldNo(NumSrcElts - 1, Elts) == Mask.size())
NumSrcElts--;
Vector codegen improvements llvm-svn: 62458
2009-01-18 14:42:49 +08:00
// modify when what gets shuffled in
reapply r148902: "use the new ConstantVector::getSplat method where it makes sense." Also simplify a bunch of code to use the Builder->getInt32 instead of doing it the hard and ugly way. Much more progress could be made here, but I don't plan to do it. llvm-svn: 148926
2012-01-25 13:34:41 +08:00
for (unsigned i = 0; i != NumSrcElts; ++i)
Mask[getAccessedFieldNo(i, Elts)] = Builder.getInt32(i+NumDstElts);
update for ConstantVector API change. llvm-svn: 125538
2011-02-15 08:14:06 +08:00
llvm::Value *MaskV = llvm::ConstantVector::get(Mask);
de-tmpify clang. llvm-svn: 140637
2011-09-28 05:06:10 +08:00
Vec = Builder.CreateShuffleVector(Vec, ExtSrcVal, MaskV);
Canonicalize else spacing. llvm-svn: 77629
2009-07-31 06:28:39 +08:00
} else {
Vector codegen improvements llvm-svn: 62458
2009-01-18 14:42:49 +08:00
// We should never shorten the vector
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("unexpected shorten vector length");
implement codegen for multidest ocuvector expressions, like: vec2.yx = vec2; // reverse llvm-svn: 40782
2007-08-04 00:37:04 +08:00
}
} else {
// If the Src is a scalar (not a vector) it must be updating one element.
Move getAccessedFieldNo out of lib/AST/Expr.cpp into lib/CodeGen/CGExpr.cpp and to change include/clang/AST/Attr.h to use its own enum for visibility types instead of using llvm::GlobalValue::VisibilityTypes. These changes eliminate dependencies in the AST library on LLVM's VMCore library. llvm-svn: 51398
2008-05-22 08:50:06 +08:00
unsigned InIdx = getAccessedFieldNo(0, Elts);
[CodeGen] Don't cast and use SizeTy instead of Int32Ty when constructing {extract,insert} vector element instructions. llvm-svn: 209942
2014-05-31 08:22:12 +08:00
llvm::Value *Elt = llvm::ConstantInt::get(SizeTy, InIdx);
de-tmpify clang. llvm-svn: 140637
2011-09-28 05:06:10 +08:00
Vec = Builder.CreateInsertElement(Vec, SrcVal, Elt);
add codegen support for storing into a single-element ocu lvalue, such as: vec2.x = f; llvm-svn: 40781
2007-08-04 00:28:33 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Builder.CreateStore(Vec, Dst.getExtVectorAddress(),
Dst.isVolatileQualified());
add codegen support for storing into a single-element ocu lvalue, such as: vec2.x = f; llvm-svn: 40781
2007-08-04 00:28:33 +08:00
}
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
/// @brief Store of global named registers are always calls to intrinsics.
void CodeGenFunction::EmitStoreThroughGlobalRegLValue(RValue Src, LValue Dst) {
Add pointer types to global named register This patch adds support for pointer types in global named registers variables. It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls. Also adds some early checks on types on SemaDecl to avoid the assert. Tests changed accordingly. (PR19837) llvm-svn: 210274
2014-06-06 00:45:22 +08:00
assert((Dst.getType()->isIntegerType() || Dst.getType()->isPointerType()) &&
"Bad type for register variable");
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
llvm::MDNode *RegName = cast<llvm::MDNode>(
cast<llvm::MetadataAsValue>(Dst.getGlobalReg())->getMetadata());
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
assert(RegName && "Register LValue is not metadata");
Add pointer types to global named register This patch adds support for pointer types in global named registers variables. It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls. Also adds some early checks on types on SemaDecl to avoid the assert. Tests changed accordingly. (PR19837) llvm-svn: 210274
2014-06-06 00:45:22 +08:00
// We accept integer and pointer types only
llvm::Type *OrigTy = CGM.getTypes().ConvertType(Dst.getType());
llvm::Type *Ty = OrigTy;
if (OrigTy->isPointerTy())
Ty = CGM.getTypes().getDataLayout().getIntPtrType(OrigTy);
llvm::Type *Types[] = { Ty };
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
llvm::Value *F = CGM.getIntrinsic(llvm::Intrinsic::write_register, Types);
llvm::Value *Value = Src.getScalarVal();
Add pointer types to global named register This patch adds support for pointer types in global named registers variables. It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls. Also adds some early checks on types on SemaDecl to avoid the assert. Tests changed accordingly. (PR19837) llvm-svn: 210274
2014-06-06 00:45:22 +08:00
if (OrigTy->isPointerTy())
Value = Builder.CreatePtrToInt(Value, Ty);
API update for streamlining of IRBuilder::CreateCall to just use ArrayRef/initializer_list+braced init llvm-svn: 237625
2015-05-19 06:14:03 +08:00
Builder.CreateCall(
F, {llvm::MetadataAsValue::get(Ty->getContext(), RegName), Value});
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
}
Clean up language and grammar. Based on a patch by jfcaron3@gmail.com! PR19806 llvm-svn: 209215
2014-05-21 01:10:39 +08:00
// setObjCGCLValueClass - sets class of the lvalue for the purpose of
Starting patch to generate more specific API for objc's GC. Currently, new API will be generated under clang-cc's -fobjc-newgc-api flag which will eventually become the default. WIP. llvm-svn: 82082
2009-09-17 05:37:16 +08:00
// generating write-barries API. It is currently a global, ivar,
// or neither.
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
static void setObjCGCLValueClass(const ASTContext &Ctx, const Expr *E,
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
LValue &LV,
bool IsMemberAccess=false) {
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (Ctx.getLangOpts().getGC() == LangOptions::NonGC)
Starting patch to generate more specific API for objc's GC. Currently, new API will be generated under clang-cc's -fobjc-newgc-api flag which will eventually become the default. WIP. llvm-svn: 82082
2009-09-17 05:37:16 +08:00
return;
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
patch for generating objc'2 objc_assign_ivar. WIP. llvm-svn: 82090
2009-09-17 07:11:23 +08:00
if (isa<ObjCIvarRefExpr>(E)) {
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
QualType ExpTy = E->getType();
if (IsMemberAccess && ExpTy->isPointerType()) {
// If ivar is a structure pointer, assigning to field of
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
// this struct follows gcc's behavior and makes it a non-ivar
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
// writer-barrier conservatively.
ExpTy = ExpTy->getAs<PointerType>()->getPointeeType();
if (ExpTy->isRecordType()) {
LV.setObjCIvar(false);
return;
}
}
IRgen: Move remaining LValue::Set... methods to LValue::set... (non-static) methods. llvm-svn: 111722
2010-08-21 11:51:29 +08:00
LV.setObjCIvar(true);
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *Exp = cast<ObjCIvarRefExpr>(const_cast<Expr *>(E));
Patch fixes a code gen. bug in generation of objc_assign_ivar (objc GC's API). llvm-svn: 82724
2009-09-25 06:25:38 +08:00
LV.setBaseIvarExp(Exp->getBase());
IRgen: Move remaining LValue::Set... methods to LValue::set... (non-static) methods. llvm-svn: 111722
2010-08-21 11:51:29 +08:00
LV.setObjCArray(E->getType()->isArrayType());
patch for generating objc'2 objc_assign_ivar. WIP. llvm-svn: 82090
2009-09-17 07:11:23 +08:00
return;
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Exp = dyn_cast<DeclRefExpr>(E)) {
if (const auto *VD = dyn_cast<VarDecl>(Exp->getDecl())) {
Death to blocks, or at least the word "block" in one particular obnoxiously ambiguous context. llvm-svn: 116567
2010-10-15 12:57:14 +08:00
if (VD->hasGlobalStorage()) {
IRgen: Move remaining LValue::Set... methods to LValue::set... (non-static) methods. llvm-svn: 111722
2010-08-21 11:51:29 +08:00
LV.setGlobalObjCRef(true);
Annotate flavor of TLS variable (statically or dynamically initialized) onto the AST. llvm-svn: 179447
2013-04-13 10:43:54 +08:00
LV.setThreadLocalRef(VD->getTLSKind() != VarDecl::TLS_None);
Adopt objc_assign_threadlocal() for __thread variables of GC types. Implements radar 8203301. llvm-svn: 108917
2010-07-21 04:30:03 +08:00
}
Starting patch to generate more specific API for objc's GC. Currently, new API will be generated under clang-cc's -fobjc-newgc-api flag which will eventually become the default. WIP. llvm-svn: 82082
2009-09-17 05:37:16 +08:00
}
IRgen: Move remaining LValue::Set... methods to LValue::set... (non-static) methods. llvm-svn: 111722
2010-08-21 11:51:29 +08:00
LV.setObjCArray(E->getType()->isArrayType());
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
return;
Starting patch to generate more specific API for objc's GC. Currently, new API will be generated under clang-cc's -fobjc-newgc-api flag which will eventually become the default. WIP. llvm-svn: 82082
2009-09-17 05:37:16 +08:00
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Exp = dyn_cast<UnaryOperator>(E)) {
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
setObjCGCLValueClass(Ctx, Exp->getSubExpr(), LV, IsMemberAccess);
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
return;
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Exp = dyn_cast<ParenExpr>(E)) {
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
setObjCGCLValueClass(Ctx, Exp->getSubExpr(), LV, IsMemberAccess);
<rdar://problem/7263113> Make clang produce gcc's objc_assign_StrongCast as a result of type-cast of an ivar in assignment. llvm-svn: 83150
2009-10-01 01:10:29 +08:00
if (LV.isObjCIvar()) {
// If cast is to a structure pointer, follow gcc's behavior and make it
// a non-ivar write-barrier.
QualType ExpTy = E->getType();
if (ExpTy->isPointerType())
ExpTy = ExpTy->getAs<PointerType>()->getPointeeType();
if (ExpTy->isRecordType())
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
LV.setObjCIvar(false);
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
}
return;
<rdar://problem/7263113> Make clang produce gcc's objc_assign_StrongCast as a result of type-cast of an ivar in assignment. llvm-svn: 83150
2009-10-01 01:10:29 +08:00
}
C1X: implement generic selections As an extension, generic selection support has been added for all supported languages. The syntax is the same as for C1X. llvm-svn: 129554
2011-04-15 08:35:48 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Exp = dyn_cast<GenericSelectionExpr>(E)) {
C1X: implement generic selections As an extension, generic selection support has been added for all supported languages. The syntax is the same as for C1X. llvm-svn: 129554
2011-04-15 08:35:48 +08:00
setObjCGCLValueClass(Ctx, Exp->getResultExpr(), LV);
return;
}
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Exp = dyn_cast<ImplicitCastExpr>(E)) {
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
setObjCGCLValueClass(Ctx, Exp->getSubExpr(), LV, IsMemberAccess);
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
return;
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Exp = dyn_cast<CStyleCastExpr>(E)) {
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
setObjCGCLValueClass(Ctx, Exp->getSubExpr(), LV, IsMemberAccess);
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
return;
}
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Exp = dyn_cast<ObjCBridgedCastExpr>(E)) {
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
setObjCGCLValueClass(Ctx, Exp->getSubExpr(), LV, IsMemberAccess);
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
return;
}
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Exp = dyn_cast<ArraySubscriptExpr>(E)) {
Starting patch to generate more specific API for objc's GC. Currently, new API will be generated under clang-cc's -fobjc-newgc-api flag which will eventually become the default. WIP. llvm-svn: 82082
2009-09-17 05:37:16 +08:00
setObjCGCLValueClass(Ctx, Exp->getBase(), LV);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
if (LV.isObjCIvar() && !LV.isObjCArray())
// Using array syntax to assigning to what an ivar points to is not
Fixed a bug in generation of the new write-barriers when array syntax is used to derefernce and assign to ivar pointee. llvm-svn: 82183
2009-09-18 08:04:00 +08:00
// same as assigning to the ivar itself. {id *Names;} Names[i] = 0;
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
LV.setObjCIvar(false);
Miscellanous fixes in generatation of objc gc's write-barriers. llvm-svn: 82472
2009-09-22 02:54:29 +08:00
else if (LV.isGlobalObjCRef() && !LV.isObjCArray())
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
// Using array syntax to assigning to what global points to is not
Miscellanous fixes in generatation of objc gc's write-barriers. llvm-svn: 82472
2009-09-22 02:54:29 +08:00
// same as assigning to the global itself. {id *G;} G[i] = 0;
IRgen: Move remaining LValue::Set... methods to LValue::set... (non-static) methods. llvm-svn: 111722
2010-08-21 11:51:29 +08:00
LV.setGlobalObjCRef(false);
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
return;
Fixed a bug in generation of the new write-barriers when array syntax is used to derefernce and assign to ivar pointee. llvm-svn: 82183
2009-09-18 08:04:00 +08:00
}
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *Exp = dyn_cast<MemberExpr>(E)) {
objc gc: assigning to an objc object struct member through an ivar pointer to this struct must go through the none ivar writer barrier. llvm-svn: 140867
2011-10-01 02:23:36 +08:00
setObjCGCLValueClass(Ctx, Exp->getBase(), LV, true);
Fixed a bug in generation of the new write-barriers when array syntax is used to derefernce and assign to ivar pointee. llvm-svn: 82183
2009-09-18 08:04:00 +08:00
// We don't know if member is an 'ivar', but this flag is looked at
// only in the context of LV.isObjCIvar().
IRgen: Move remaining LValue::Set... methods to LValue::set... (non-static) methods. llvm-svn: 111722
2010-08-21 11:51:29 +08:00
LV.setObjCArray(E->getType()->isArrayType());
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
return;
Starting patch to generate more specific API for objc's GC. Currently, new API will be generated under clang-cc's -fobjc-newgc-api flag which will eventually become the default. WIP. llvm-svn: 82082
2009-09-17 05:37:16 +08:00
}
}
Fix a problem Eli ran into where we now reject incomplete arrays of uncompleted struct types. We now do what llvm-gcc does and compile them into [i8 x 0]. If the type is later completed, we make sure that it is appropriately cast. We compile the terrible example to something like this now: %struct.A = type { i32, i32, i32 } @g = external global [0 x i8] define void @_Z1fv() nounwind { entry: call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*)) ret void } declare void @_Z3fooP1A(%struct.A*) define %struct.A* @_Z2f2v() nounwind { entry: ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1) } llvm-svn: 134972
2011-07-12 14:52:18 +08:00
static llvm::Value *
Work around a problem with a static helper's formulation in release builds introduced in r134972: lib/CodeGen/CGExpr.cpp:1294:7: error: no matching function for call to 'EmitBitCastOfLValueToProperType' lib/CodeGen/CGExpr.cpp:1278:1: note: candidate function not viable: no known conversion from 'CGBuilderTy' (aka 'IRBuilder<false>') to 'llvm::IRBuilder<> &' for 1st argument This fixes the issue by passing CodeGenFunction on down, and using its builder directly rather than passing just the builder down. This may not be the best / cleanest fix, Chris please review. It at least fixes builds. llvm-svn: 134977
2011-07-12 16:58:26 +08:00
EmitBitCastOfLValueToProperType(CodeGenFunction &CGF,
Fix a problem Eli ran into where we now reject incomplete arrays of uncompleted struct types. We now do what llvm-gcc does and compile them into [i8 x 0]. If the type is later completed, we make sure that it is appropriately cast. We compile the terrible example to something like this now: %struct.A = type { i32, i32, i32 } @g = external global [0 x i8] define void @_Z1fv() nounwind { entry: call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*)) ret void } declare void @_Z3fooP1A(%struct.A*) define %struct.A* @_Z2f2v() nounwind { entry: ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1) } llvm-svn: 134972
2011-07-12 14:52:18 +08:00
llvm::Value *V, llvm::Type *IRType,
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
StringRef Name = StringRef()) {
Fix a problem Eli ran into where we now reject incomplete arrays of uncompleted struct types. We now do what llvm-gcc does and compile them into [i8 x 0]. If the type is later completed, we make sure that it is appropriately cast. We compile the terrible example to something like this now: %struct.A = type { i32, i32, i32 } @g = external global [0 x i8] define void @_Z1fv() nounwind { entry: call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*)) ret void } declare void @_Z3fooP1A(%struct.A*) define %struct.A* @_Z2f2v() nounwind { entry: ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1) } llvm-svn: 134972
2011-07-12 14:52:18 +08:00
unsigned AS = cast<llvm::PointerType>(V->getType())->getAddressSpace();
Work around a problem with a static helper's formulation in release builds introduced in r134972: lib/CodeGen/CGExpr.cpp:1294:7: error: no matching function for call to 'EmitBitCastOfLValueToProperType' lib/CodeGen/CGExpr.cpp:1278:1: note: candidate function not viable: no known conversion from 'CGBuilderTy' (aka 'IRBuilder<false>') to 'llvm::IRBuilder<> &' for 1st argument This fixes the issue by passing CodeGenFunction on down, and using its builder directly rather than passing just the builder down. This may not be the best / cleanest fix, Chris please review. It at least fixes builds. llvm-svn: 134977
2011-07-12 16:58:26 +08:00
return CGF.Builder.CreateBitCast(V, IRType->getPointerTo(AS), Name);
Fix a problem Eli ran into where we now reject incomplete arrays of uncompleted struct types. We now do what llvm-gcc does and compile them into [i8 x 0]. If the type is later completed, we make sure that it is appropriately cast. We compile the terrible example to something like this now: %struct.A = type { i32, i32, i32 } @g = external global [0 x i8] define void @_Z1fv() nounwind { entry: call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*)) ret void } declare void @_Z3fooP1A(%struct.A*) define %struct.A* @_Z2f2v() nounwind { entry: ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1) } llvm-svn: 134972
2011-07-12 14:52:18 +08:00
}
[OPENMP] Codegen for threadprivate variables For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
2014-11-11 12:05:39 +08:00
static LValue EmitThreadPrivateVarDeclLValue(
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CodeGenFunction &CGF, const VarDecl *VD, QualType T, Address Addr,
llvm::Type *RealVarTy, SourceLocation Loc) {
Addr = CGF.CGM.getOpenMPRuntime().getAddrOfThreadPrivate(CGF, VD, Addr, Loc);
Addr = CGF.Builder.CreateElementBitCast(Addr, RealVarTy);
return CGF.MakeAddrLValue(Addr, T, AlignmentSource::Decl);
}
Address CodeGenFunction::EmitLoadOfReference(Address Addr,
const ReferenceType *RefTy,
AlignmentSource *Source) {
llvm::Value *Ptr = Builder.CreateLoad(Addr);
return Address(Ptr, getNaturalTypeAlignment(RefTy->getPointeeType(),
Source, /*forPointee*/ true));
}
LValue CodeGenFunction::EmitLoadOfReferenceLValue(Address RefAddr,
const ReferenceType *RefTy) {
AlignmentSource Source;
Address Addr = EmitLoadOfReference(RefAddr, RefTy, &Source);
return MakeAddrLValue(Addr, RefTy->getPointeeType(), Source);
[OPENMP] Codegen for threadprivate variables For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
2014-11-11 12:05:39 +08:00
}
More LValue related code cleanup. llvm-svn: 86413
2009-11-08 07:06:58 +08:00
static LValue EmitGlobalVarDeclLValue(CodeGenFunction &CGF,
const Expr *E, const VarDecl *VD) {
PR19254: If a thread_local data member of a class is accessed via member access syntax, don't forget to run its initializer. llvm-svn: 204869
2014-03-27 06:48:22 +08:00
QualType T = E->getType();
// If it's thread_local, emit a call to its wrapper function instead.
MS ABI: Implement thread_local for global variables Summary: This add support for the C++11 feature, thread_local global variables. The ABI Clang implements is an improvement of the MSVC ABI. Sadly, further improvements could be made but not without sacrificing ABI compatibility. The feature is implemented as follows: - All thread_local initialization routines are pointed to from the .CRT$XDU section. - All non-weak thread_local variables have their initialization routines call from a single function instead of getting their own .CRT$XDU section entry. This is done to open up optimization opportunities to the compiler. - All weak thread_local variables have their own .CRT$XDU section entry. This entry is in a COMDAT with the global variable it is initializing; this ensures that we will initialize the global exactly once. - Destructors are registered in the initialization function using __tlregdtor. Differential Revision: http://reviews.llvm.org/D5597 llvm-svn: 219074
2014-10-05 13:05:40 +08:00
if (VD->getTLSKind() == VarDecl::TLS_Dynamic &&
CGF.CGM.getCXXABI().usesThreadWrapperFunction())
PR19254: If a thread_local data member of a class is accessed via member access syntax, don't forget to run its initializer. llvm-svn: 204869
2014-03-27 06:48:22 +08:00
return CGF.CGM.getCXXABI().EmitThreadLocalVarDeclLValue(CGF, VD, T);
More LValue related code cleanup. llvm-svn: 86413
2009-11-08 07:06:58 +08:00
llvm::Value *V = CGF.CGM.GetAddrOfGlobalVar(VD);
Fix a bunch of really nasty bugs in how we compute alignment for reference lvalues. PR11376. llvm-svn: 144745
2011-11-16 08:42:57 +08:00
llvm::Type *RealVarTy = CGF.getTypes().ConvertTypeForMem(VD->getType());
V = EmitBitCastOfLValueToProperType(CGF, V, RealVarTy);
Switch LValue so that it exposes alignment in CharUnits. (No functional change.) llvm-svn: 145753
2011-12-03 12:14:32 +08:00
CharUnits Alignment = CGF.getContext().getDeclAlign(VD);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Addr(V, Alignment);
Fix a bunch of really nasty bugs in how we compute alignment for reference lvalues. PR11376. llvm-svn: 144745
2011-11-16 08:42:57 +08:00
LValue LV;
[OPENMP] Codegen for threadprivate variables For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
2014-11-11 12:05:39 +08:00
// Emit reference to the private copy of the variable if it is an OpenMP
// threadprivate variable.
if (CGF.getLangOpts().OpenMP && VD->hasAttr<OMPThreadPrivateDeclAttr>())
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return EmitThreadPrivateVarDeclLValue(CGF, VD, T, Addr, RealVarTy,
[OPENMP] Codegen for threadprivate variables For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
2014-11-11 12:05:39 +08:00
E->getExprLoc());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
if (auto RefTy = VD->getType()->getAs<ReferenceType>()) {
LV = CGF.EmitLoadOfReferenceLValue(Addr, RefTy);
Fix a bunch of really nasty bugs in how we compute alignment for reference lvalues. PR11376. llvm-svn: 144745
2011-11-16 08:42:57 +08:00
} else {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LV = CGF.MakeAddrLValue(Addr, T, AlignmentSource::Decl);
Fix a bunch of really nasty bugs in how we compute alignment for reference lvalues. PR11376. llvm-svn: 144745
2011-11-16 08:42:57 +08:00
}
More LValue related code cleanup. llvm-svn: 86413
2009-11-08 07:06:58 +08:00
setObjCGCLValueClass(CGF.getContext(), E, LV);
return LV;
}
Implement IRGen for MemberExpr referring to static member function. llvm-svn: 89938
2009-11-26 14:08:14 +08:00
static LValue EmitFunctionDeclLValue(CodeGenFunction &CGF,
change EmitLValueForField to cast the returned lvalue to the right type, even when in the struct case. This was one root issue that was causing type mismatches throughout the compiler. llvm-svn: 134862
2011-07-10 13:34:54 +08:00
const Expr *E, const FunctionDecl *FD) {
clean up some formatting. llvm-svn: 113129
2010-09-06 08:11:41 +08:00
llvm::Value *V = CGF.CGM.GetAddrOfFunction(FD);
Implement IRGen for MemberExpr referring to static member function. llvm-svn: 89938
2009-11-26 14:08:14 +08:00
if (!FD->hasPrototype()) {
if (const FunctionProtoType *Proto =
FD->getType()->getAs<FunctionProtoType>()) {
// Ugly case: for a K&R-style definition, the type of the definition
// isn't the same as the type of a use. Correct for this with a
// bitcast.
QualType NoProtoType =
Rename getResultType() on function and method declarations to getReturnType() A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
2014-01-26 00:55:45 +08:00
CGF.getContext().getFunctionNoProtoType(Proto->getReturnType());
Implement IRGen for MemberExpr referring to static member function. llvm-svn: 89938
2009-11-26 14:08:14 +08:00
NoProtoType = CGF.getContext().getPointerType(NoProtoType);
de-tmpify clang. llvm-svn: 140637
2011-09-28 05:06:10 +08:00
V = CGF.Builder.CreateBitCast(V, CGF.ConvertType(NoProtoType));
Implement IRGen for MemberExpr referring to static member function. llvm-svn: 89938
2009-11-26 14:08:14 +08:00
}
}
Switch LValue so that it exposes alignment in CharUnits. (No functional change.) llvm-svn: 145753
2011-12-03 12:14:32 +08:00
CharUnits Alignment = CGF.getContext().getDeclAlign(FD);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return CGF.MakeAddrLValue(V, E->getType(), Alignment, AlignmentSource::Decl);
Implement IRGen for MemberExpr referring to static member function. llvm-svn: 89938
2009-11-26 14:08:14 +08:00
}
CodeGen for CapturedStmts EmitCapturedStmt creates a captured struct containing all of the captured variables, and then emits a call to the outlined function. This is similar in principle to EmitBlockLiteral. GenerateCapturedFunction actually produces the outlined function. It is based on GenerateBlockFunction, but is much simpler. The function type is determined by the parameters that are in the CapturedDecl. Some changes have been added to this patch that were reviewed as part of the serialization patch and moving the parameters to the captured decl. Differential Revision: http://llvm-reviews.chandlerc.com/D640 llvm-svn: 181536
2013-05-10 03:17:11 +08:00
static LValue EmitCapturedFieldLValue(CodeGenFunction &CGF, const FieldDecl *FD,
llvm::Value *ThisValue) {
QualType TagType = CGF.getContext().getTagDeclType(FD->getParent());
LValue LV = CGF.MakeNaturalAlignAddrLValue(ThisValue, TagType);
return CGF.EmitLValueForField(LV, FD);
}
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
/// Named Registers are named metadata pointing to the register name
/// which will be read from/written to as an argument to the intrinsic
/// @llvm.read/write_register.
/// So far, only the name is being passed down, but other options such as
/// register type, allocation type or even optimization options could be
/// passed down via the metadata node.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
static LValue EmitGlobalNamedRegister(const VarDecl *VD, CodeGenModule &CGM) {
Using SmallString and correct addr var llvm-svn: 209180
2014-05-20 07:25:25 +08:00
SmallString<64> Name("llvm.named.register.");
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
AsmLabelAttr *Asm = VD->getAttr<AsmLabelAttr>();
Using SmallString and correct addr var llvm-svn: 209180
2014-05-20 07:25:25 +08:00
assert(Asm->getLabel().size() < 64-Name.size() &&
"Register name too big");
Name.append(Asm->getLabel());
Fix usage of string when StringRef was needed Also adding a variable to the test, so release bots match %1. This should also calm the gdb buildbot. . llvm-svn: 209171
2014-05-20 06:36:19 +08:00
llvm::NamedMDNode *M =
Using SmallString and correct addr var llvm-svn: 209180
2014-05-20 07:25:25 +08:00
CGM.getModule().getOrInsertNamedMetadata(Name);
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
if (M->getNumOperands() == 0) {
llvm::MDString *Str = llvm::MDString::get(CGM.getLLVMContext(),
Asm->getLabel());
IR: Update clang for Metadata/Value split in r223802 Match LLVM API changes from r223802. llvm-svn: 223803
2014-12-10 02:39:32 +08:00
llvm::Metadata *Ops[] = {Str};
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
M->addOperand(llvm::MDNode::get(CGM.getLLVMContext(), Ops));
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits Alignment = CGM.getContext().getDeclAlign(VD);
llvm::Value *Ptr =
llvm::MetadataAsValue::get(CGM.getLLVMContext(), M->getOperand(0));
return LValue::MakeGlobalReg(Address(Ptr, Alignment), VD->getType());
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
}
Implement scaffolding for lvalues. Implement block vardecl lvalues. This allows us to translate: int func() { register int X; { int Y; return 1+X+Y; } } into: define i32 @func() { entry: %X = alloca i32 ; <i32*> [#uses=1] %Y = alloca i32 ; <i32*> [#uses=1] %allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0] %tmp = load i32* %X ; <i32> [#uses=1] %tmp1 = add i32 1, %tmp ; <i32> [#uses=1] %tmp2 = load i32* %Y ; <i32> [#uses=1] %tmp3 = add i32 %tmp1, %tmp2 ; <i32> [#uses=1] ret i32 %tmp3 ; No predecessors! ret i32 undef } llvm-svn: 39555
2007-06-02 13:24:33 +08:00
LValue CodeGenFunction::EmitDeclRefLValue(const DeclRefExpr *E) {
More cleanup, the code is much easier to follow now. llvm-svn: 86412
2009-11-08 06:53:10 +08:00
const NamedDecl *ND = E->getDecl();
Fix a bunch of really nasty bugs in how we compute alignment for reference lvalues. PR11376. llvm-svn: 144745
2011-11-16 08:42:57 +08:00
QualType T = E->getType();
Non-allocatable Global Named Register This patch implements global named registers in Clang, lowering to the just created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue had to be created (Register), which just adds support to carry the metadata node containing the name of the register. Two new methods to emit loads and stores interoperate with another to emit the named metadata node. No guarantees are being made and only non-allocatable global variable named registers are being supported. Local named register support is unchanged. llvm-svn: 209149
2014-05-20 02:15:42 +08:00
Revert small change to EmitDeclRefLValue That small change, although it looked harmless, it made emitting the LValue on the PHI node without the proper cast. Reverting it fixes PR19841. llvm-svn: 209663
2014-05-28 00:46:27 +08:00
if (const auto *VD = dyn_cast<VarDecl>(ND)) {
// Global Named registers access via intrinsics only
if (VD->getStorageClass() == SC_Register &&
VD->hasAttr<AsmLabelAttr>() && !VD->isLocalVarDecl())
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return EmitGlobalNamedRegister(VD, CGM);
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Revert small change to EmitDeclRefLValue That small change, although it looked harmless, it made emitting the LValue on the PHI node without the proper cast. Reverting it fixes PR19841. llvm-svn: 209663
2014-05-28 00:46:27 +08:00
// A DeclRefExpr for a reference initialized by a constant expression can
// appear without being odr-used. Directly emit the constant initializer.
DR1472: A reference isn't odr-used if it has preceding initialization, initialized by a reference constant expression. Our odr-use modeling still needs work here: we don't yet implement the 'set of potential results of an expression' DR. llvm-svn: 166361
2012-10-20 09:38:33 +08:00
const Expr *Init = VD->getAnyInitializer(VD);
if (Init && !isa<ParmVarDecl>(VD) && VD->getType()->isReferenceType() &&
VD->isUsableInConstantExpressions(getContext()) &&
VD->checkInitIsICE()) {
llvm::Constant *Val =
CGM.EmitConstantValue(*VD->evaluateValue(), VD->getType(), this);
assert(Val && "failed to emit reference constant expression");
// FIXME: Eventually we will want to emit vector element references.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// Should we be using the alignment of the constant pointer we emitted?
CharUnits Alignment = getNaturalTypeAlignment(E->getType(), nullptr,
/*pointee*/ true);
return MakeAddrLValue(Address(Val, Alignment), T, AlignmentSource::Decl);
DR1472: A reference isn't odr-used if it has preceding initialization, initialized by a reference constant expression. Our odr-use modeling still needs work here: we don't yet implement the 'set of potential results of an expression' DR. llvm-svn: 166361
2012-10-20 09:38:33 +08:00
}
CodeGen: Don't crash when a lambda uses a local constexpr variable The DeclRefExpr might be for a variable initialized by a constant expression which hasn't been ODR used. Emit the initializer for the variable instead of trying to capture the variable itself. This fixes PR22071. llvm-svn: 225060
2015-01-01 17:49:44 +08:00
// Check for captured variables.
Rename RefersToCapturedVariable to RefersToEnclosingVariableOrCapture, NFC llvm-svn: 225624
2015-01-12 18:17:46 +08:00
if (E->refersToEnclosingVariableOrCapture()) {
CodeGen: Don't crash when a lambda uses a local constexpr variable The DeclRefExpr might be for a variable initialized by a constant expression which hasn't been ODR used. Emit the initializer for the variable instead of trying to capture the variable itself. This fixes PR22071. llvm-svn: 225060
2015-01-01 17:49:44 +08:00
if (auto *FD = LambdaCaptureFields.lookup(VD))
return EmitCapturedFieldLValue(*this, FD, CXXABIThisValue);
else if (CapturedStmtInfo) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
auto it = LocalDeclMap.find(VD);
if (it != LocalDeclMap.end()) {
if (auto RefTy = VD->getType()->getAs<ReferenceType>()) {
return EmitLoadOfReferenceLValue(it->second, RefTy);
[OPENMP] Fix for http://llvm.org/PR24674: assertion failed and and abort trap Fix processing of shared variables with reference types in OpenMP constructs. Previously, if the variable was not marked in one of the private clauses, the reference to this variable was emitted incorrectly and caused an assertion later. llvm-svn: 246846
2015-09-04 19:26:21 +08:00
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(it->second, T);
[OPENMP] Fix for http://llvm.org/PR24674: assertion failed and and abort trap Fix processing of shared variables with reference types in OpenMP constructs. Previously, if the variable was not marked in one of the private clauses, the reference to this variable was emitted incorrectly and caused an assertion later. llvm-svn: 246846
2015-09-04 19:26:21 +08:00
}
return EmitCapturedFieldLValue(*this, CapturedStmtInfo->lookup(VD),
CapturedStmtInfo->getContextValue());
CodeGen: Don't crash when a lambda uses a local constexpr variable The DeclRefExpr might be for a variable initialized by a constant expression which hasn't been ODR used. Emit the initializer for the variable instead of trying to capture the variable itself. This fixes PR22071. llvm-svn: 225060
2015-01-01 17:49:44 +08:00
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CodeGen: Don't crash when a lambda uses a local constexpr variable The DeclRefExpr might be for a variable initialized by a constant expression which hasn't been ODR used. Emit the initializer for the variable instead of trying to capture the variable itself. This fixes PR22071. llvm-svn: 225060
2015-01-01 17:49:44 +08:00
assert(isa<BlockDecl>(CurCodeDecl));
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address addr = GetAddrOfBlockDecl(VD, VD->hasAttr<BlocksAttr>());
return MakeAddrLValue(addr, T, AlignmentSource::Decl);
CodeGen: Don't crash when a lambda uses a local constexpr variable The DeclRefExpr might be for a variable initialized by a constant expression which hasn't been ODR used. Emit the initializer for the variable instead of trying to capture the variable itself. This fixes PR22071. llvm-svn: 225060
2015-01-01 17:49:44 +08:00
}
DR1472: A reference isn't odr-used if it has preceding initialization, initialized by a reference constant expression. Our odr-use modeling still needs work here: we don't yet implement the 'set of potential results of an expression' DR. llvm-svn: 166361
2012-10-20 09:38:33 +08:00
}
Add an assertion that our use-marking actually covers all uses of a variable. The assertion doesn't cover quite as much as it should, but it's a good start, at least. llvm-svn: 148625
2012-01-21 12:52:58 +08:00
// FIXME: We should be able to assert this for FunctionDecls as well!
// FIXME: We should be able to assert this for all DeclRefExprs, not just
// those with a valid source location.
assert((ND->isUsed(false) || !isa<VarDecl>(ND) ||
!E->getLocation().isValid()) &&
"Should not use decl without marking it used!");
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
if (ND->hasAttr<WeakRefAttr>()) {
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *VD = cast<ValueDecl>(ND);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ConstantAddress Aliasee = CGM.GetWeakRefReference(VD);
return MakeAddrLValue(Aliasee, T, AlignmentSource::Decl);
Fix PR6473. Clang's support for weakref is now better than llvm-gcc's :-) We don't introduce a new symbol and we correctly mark undefined references weak only if there is no definition or regular undefined references in the same file. llvm-svn: 97733
2010-03-05 02:17:24 +08:00
}
Revert small change to EmitDeclRefLValue That small change, although it looked harmless, it made emitting the LValue on the PHI node without the proper cast. Reverting it fixes PR19841. llvm-svn: 209663
2014-05-28 00:46:27 +08:00
if (const auto *VD = dyn_cast<VarDecl>(ND)) {
More cleanup, the code is much easier to follow now. llvm-svn: 86412
2009-11-08 06:53:10 +08:00
// Check if this is a global variable.
PR19254: If a thread_local data member of a class is accessed via member access syntax, don't forget to run its initializer. llvm-svn: 204869
2014-03-27 06:48:22 +08:00
if (VD->hasLinkage() || VD->isStaticDataMember())
More LValue related code cleanup. llvm-svn: 86413
2009-11-08 07:06:58 +08:00
return EmitGlobalVarDeclLValue(*this, E, VD);
We only need to call SetObjCNonGC for local variables. No functionality change. llvm-svn: 86410
2009-11-08 06:43:34 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address addr = Address::invalid();
Remove BlockDeclRefExpr and introduce a bit on DeclRefExpr to track whether the referenced declaration comes from an enclosing local context. I'm amenable to suggestions about the exact meaning of this bit. llvm-svn: 152491
2012-03-10 17:33:50 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// The variable should generally be present in the local decl map.
auto iter = LocalDeclMap.find(VD);
if (iter != LocalDeclMap.end()) {
addr = iter->second;
Basic support for referring to captured variables from lambdas. Some simple examples seem to work. Tests coming up soon. llvm-svn: 150293
2012-02-11 10:57:39 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// Otherwise, it might be static local we haven't emitted yet for
// some reason; most likely, because it's in an outer function.
} else if (VD->isStaticLocal()) {
addr = Address(CGM.getOrCreateStaticVarDecl(
*VD, CGM.getLLVMLinkageVarDefinition(VD, /*isConstant=*/false)),
getContext().getDeclAlign(VD));
// No other cases for now.
} else {
llvm_unreachable("DeclRefExpr for Decl not entered in LocalDeclMap?");
}
[OPENMP] Codegen for threadprivate variables For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>); In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>); Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info. Differential Revision: http://reviews.llvm.org/D4002 llvm-svn: 221663
2014-11-11 12:05:39 +08:00
Refactor the representation of qualifiers to bring ExtQualType out of the Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our use of qualifiers and fix a few places that weren't dealing with qualifiers quite right; many more remain. llvm-svn: 82705
2009-09-25 03:53:00 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// Check for OpenMP threadprivate variables.
if (getLangOpts().OpenMP && VD->hasAttr<OMPThreadPrivateDeclAttr>()) {
return EmitThreadPrivateVarDeclLValue(
*this, VD, T, addr, getTypes().ConvertTypeForMem(VD->getType()),
E->getExprLoc());
}
// Drill into block byref variables.
bool isBlockByref = VD->hasAttr<BlocksAttr>();
if (isBlockByref) {
addr = emitBlockByrefAddress(addr, VD);
}
IRgen: Move remaining MakeAddr() calls to MakeAddrLValue(). llvm-svn: 111721
2010-08-21 11:44:13 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// Drill into reference types.
Fix a bunch of really nasty bugs in how we compute alignment for reference lvalues. PR11376. llvm-svn: 144745
2011-11-16 08:42:57 +08:00
LValue LV;
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
if (auto RefTy = VD->getType()->getAs<ReferenceType>()) {
LV = EmitLoadOfReferenceLValue(addr, RefTy);
Fix a bunch of really nasty bugs in how we compute alignment for reference lvalues. PR11376. llvm-svn: 144745
2011-11-16 08:42:57 +08:00
} else {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LV = MakeAddrLValue(addr, T, AlignmentSource::Decl);
Fix a bunch of really nasty bugs in how we compute alignment for reference lvalues. PR11376. llvm-svn: 144745
2011-11-16 08:42:57 +08:00
}
Fix a problem Eli ran into where we now reject incomplete arrays of uncompleted struct types. We now do what llvm-gcc does and compile them into [i8 x 0]. If the type is later completed, we make sure that it is appropriately cast. We compile the terrible example to something like this now: %struct.A = type { i32, i32, i32 } @g = external global [0 x i8] define void @_Z1fv() nounwind { entry: call void @_Z3fooP1A(%struct.A* bitcast ([0 x i8]* @g to %struct.A*)) ret void } declare void @_Z3fooP1A(%struct.A*) define %struct.A* @_Z2f2v() nounwind { entry: ret %struct.A* getelementptr inbounds ([0 x %struct.A]* bitcast ([0 x i8]* @g to [0 x %struct.A]*), i32 0, i64 1) } llvm-svn: 134972
2011-07-12 14:52:18 +08:00
Tighten up the rules for precise lifetime and document the requirements on the ARC optimizer. rdar://13407451 llvm-svn: 176924
2013-03-13 11:10:54 +08:00
bool isLocalStorage = VD->hasLocalStorage();
bool NonGCable = isLocalStorage &&
!VD->getType()->isReferenceType() &&
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
!isBlockByref;
Minor cleanup. No change otherwise. llvm-svn: 119814
2010-11-20 02:17:09 +08:00
if (NonGCable) {
IRgen: Move remaining MakeAddr() calls to MakeAddrLValue(). llvm-svn: 111721
2010-08-21 11:44:13 +08:00
LV.getQuals().removeObjCGCAttr();
IRgen/LValue: Add LValue::setNonGC instead of SetObjCNonGC, for consistency with isNonGC(). llvm-svn: 111718
2010-08-21 11:22:38 +08:00
LV.setNonGC(true);
}
Tighten up the rules for precise lifetime and document the requirements on the ARC optimizer. rdar://13407451 llvm-svn: 176924
2013-03-13 11:10:54 +08:00
bool isImpreciseLifetime =
(isLocalStorage && !VD->hasAttr<ObjCPreciseLifetimeAttr>());
if (isImpreciseLifetime)
LV.setARCPreciseLifetime(ARCImpreciseLifetime);
Starting patch to generate more specific API for objc's GC. Currently, new API will be generated under clang-cc's -fobjc-newgc-api flag which will eventually become the default. WIP. llvm-svn: 82082
2009-09-17 05:37:16 +08:00
setObjCGCLValueClass(getContext(), E, LV);
More objc gc stuff. Read/Write barriers for local static/extern, diagnostics on use of __weak attribute on fields, Early support for read/write barriers for objc fields. llvm-svn: 59682
2008-11-20 08:15:42 +08:00
return LV;
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
}
More capturing of 'this': implicit member expressions. Getting that right for anonymous struct/union members led to me discovering some seemingly broken code in that area of Sema, which I fixed, partly by changing the representation of member pointer constants so that IndirectFieldDecls aren't expanded. This led to assorted cleanups with member pointers in CodeGen, and while I was doing that I saw some random other things to clean up. llvm-svn: 124785
2011-02-03 16:15:49 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *FD = dyn_cast<FunctionDecl>(ND))
C++1y sized deallocation: if we have a use, but not a definition, of a sized deallocation function (and the corresponding unsized deallocation function has been declared), emit a weak discardable definition of the function that forwards to the corresponding unsized deallocation. This allows a C++ standard library implementation to provide both a sized and an unsized deallocation function, where the unsized one does not just call the sized one, for instance by putting both in the same object file within an archive. llvm-svn: 194055
2013-11-05 17:12:18 +08:00
return EmitFunctionDeclLValue(*this, E, FD);
More capturing of 'this': implicit member expressions. Getting that right for anonymous struct/union members led to me discovering some seemingly broken code in that area of Sema, which I fixed, partly by changing the representation of member pointer constants so that IndirectFieldDecls aren't expanded. This led to assorted cleanups with member pointers in CodeGen, and while I was doing that I saw some random other things to clean up. llvm-svn: 124785
2011-02-03 16:15:49 +08:00
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Unhandled DeclRefExpr");
Implement scaffolding for lvalues. Implement block vardecl lvalues. This allows us to translate: int func() { register int X; { int Y; return 1+X+Y; } } into: define i32 @func() { entry: %X = alloca i32 ; <i32*> [#uses=1] %Y = alloca i32 ; <i32*> [#uses=1] %allocapt = bitcast i32 undef to i32 ; <i32> [#uses=0] %tmp = load i32* %X ; <i32> [#uses=1] %tmp1 = add i32 1, %tmp ; <i32> [#uses=1] %tmp2 = load i32* %Y ; <i32> [#uses=1] %tmp3 = add i32 %tmp1, %tmp2 ; <i32> [#uses=1] ret i32 %tmp3 ; No predecessors! ret i32 undef } llvm-svn: 39555
2007-06-02 13:24:33 +08:00
}
split stmt/expr codegen into their own files. llvm-svn: 39540
2007-06-02 02:02:12 +08:00
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
LValue CodeGenFunction::EmitUnaryOpLValue(const UnaryOperator *E) {
// __extension__ doesn't affect lvalue-ness.
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
if (E->getOpcode() == UO_Extension)
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
return EmitLValue(E->getSubExpr());
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
remove uses of QualType::getCanonicalType() from codegen for PR2189 llvm-svn: 54107
2008-07-27 06:37:01 +08:00
QualType ExprTy = getContext().getCanonicalType(E->getSubExpr()->getType());
__real__ and __imag__ can be lvalues. Add support to ast and codegen for them. llvm-svn: 43525
2007-10-31 06:53:42 +08:00
switch (E->getOpcode()) {
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
default: llvm_unreachable("Unknown unary operator lvalue!");
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case UO_Deref: {
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
QualType T = E->getSubExpr()->getType()->getPointeeType();
assert(!T.isNull() && "CodeGenFunction::EmitUnaryOpLValue: Illegal type");
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
AlignmentSource AlignSource;
Address Addr = EmitPointerWithAlignment(E->getSubExpr(), &AlignSource);
LValue LV = MakeAddrLValue(Addr, T, AlignSource);
IRgen: Move remaining MakeAddr() calls to MakeAddrLValue(). llvm-svn: 111721
2010-08-21 11:44:13 +08:00
LV.getQuals().setAddressSpace(ExprTy.getAddressSpace());
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
// We should not generate __weak write barrier on indirect reference
// of a pointer to object; as in void foo (__weak id *param); *param = 0;
// But, we continue to generate __strong write barrier on indirect write
// into a pointer to object.
Simplify: replace getContext().getLangOpts() with just getLangOpts(). llvm-svn: 167261
2012-11-02 06:30:59 +08:00
if (getLangOpts().ObjC1 &&
getLangOpts().getGC() != LangOptions::NonGC &&
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
LV.isObjCWeak())
IRgen/LValue: Add LValue::setNonGC instead of SetObjCNonGC, for consistency with isNonGC(). llvm-svn: 111718
2010-08-21 11:22:38 +08:00
LV.setNonGC(!E->isOBJCGCCandidate(getContext()));
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
return LV;
}
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case UO_Real:
case UO_Imag: {
__real__ and __imag__ can be lvalues. Add support to ast and codegen for them. llvm-svn: 43525
2007-10-31 06:53:42 +08:00
LValue LV = EmitLValue(E->getSubExpr());
Fix a bug in the emission of __real/__imag l-values on scalar operands. Fix a bug in the emission of complex compound assignment l-values. Introduce a method to emit an expression whose value isn't relevant. Make that method evaluate its operand as an l-value if it is one. Fixes our volatile compliance in C++. llvm-svn: 120931
2010-12-05 10:00:02 +08:00
assert(LV.isSimple() && "real/imag on non-ordinary l-value");
Fix wrong-code bug: __imag on a scalar lvalue should produce a zero rvalue, rather than an lvalue referring to the scalar. llvm-svn: 150889
2012-02-19 04:53:32 +08:00
// __real is valid on scalars. This is a faster way of testing that.
// __imag can only produce an rvalue on scalars.
if (E->getOpcode() == UO_Real &&
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
!LV.getAddress().getElementType()->isStructTy()) {
Fix a bug in the emission of __real/__imag l-values on scalar operands. Fix a bug in the emission of complex compound assignment l-values. Introduce a method to emit an expression whose value isn't relevant. Make that method evaluate its operand as an l-value if it is one. Fixes our volatile compliance in C++. llvm-svn: 120931
2010-12-05 10:00:02 +08:00
assert(E->getSubExpr()->getType()->isArithmeticType());
return LV;
}
assert(E->getSubExpr()->getType()->isAnyComplexType());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Component =
(E->getOpcode() == UO_Real
? emitAddrOfRealComponent(LV.getAddress(), LV.getType())
: emitAddrOfImagComponent(LV.getAddress(), LV.getType()));
return MakeAddrLValue(Component, ExprTy, LV.getAlignmentSource());
__real__ and __imag__ can be lvalues. Add support to ast and codegen for them. llvm-svn: 43525
2007-10-31 06:53:42 +08:00
}
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case UO_PreInc:
case UO_PreDec: {
implement codegen support for preinc as an lvalue, PR5514. llvm-svn: 93076
2010-01-10 05:44:40 +08:00
LValue LV = EmitLValue(E->getSubExpr());
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
bool isInc = E->getOpcode() == UO_PreInc;
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
implement codegen support for preinc as an lvalue, PR5514. llvm-svn: 93076
2010-01-10 05:44:40 +08:00
if (E->getType()->isAnyComplexType())
EmitComplexPrePostIncDec(E, LV, isInc, true/*isPre*/);
else
EmitScalarPrePostIncDec(E, LV, isInc, true/*isPre*/);
return LV;
}
Explicitly note that pre-inc/dec lvalues are not supported yet, so that it doesn't crash. (Such expressions are valid in C++, but not in C.) llvm-svn: 86513
2009-11-09 12:20:47 +08:00
}
implement codegen of a bunch more loop constructs and most expressions llvm-svn: 39593
2007-06-06 04:53:16 +08:00
}
implement codegen of string literals. llvm-svn: 39597
2007-06-06 12:54:52 +08:00
LValue CodeGenFunction::EmitStringLiteralLValue(const StringLiteral *E) {
IRgen: Switch more MakeAddr() users to MakeAddrLValue; this time for calls which were previously not computing the qualifier list. In most cases, I don't think it matters, but I believe this is conservatively more correct / consistent. llvm-svn: 111717
2010-08-21 11:15:20 +08:00
return MakeAddrLValue(CGM.GetAddrOfConstantStringFromLiteral(E),
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
E->getType(), AlignmentSource::Decl);
implement codegen of string literals. llvm-svn: 39597
2007-06-06 12:54:52 +08:00
}
first wave of fixes for @encode sema support. This is part of PR3648. The big difference here is that (like string literal) @encode has array type, not pointer type. llvm-svn: 65391
2009-02-25 06:18:39 +08:00
LValue CodeGenFunction::EmitObjCEncodeExprLValue(const ObjCEncodeExpr *E) {
IRgen: Switch more MakeAddr() users to MakeAddrLValue; this time for calls which were previously not computing the qualifier list. In most cases, I don't think it matters, but I believe this is conservatively more correct / consistent. llvm-svn: 111717
2010-08-21 11:15:20 +08:00
return MakeAddrLValue(CGM.GetAddrOfConstantStringFromObjCEncode(E),
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
E->getType(), AlignmentSource::Decl);
first wave of fixes for @encode sema support. This is part of PR3648. The big difference here is that (like string literal) @encode has array type, not pointer type. llvm-svn: 65391
2009-02-25 06:18:39 +08:00
}
IRgen: Eliminate EmitPredefinedFunctionName(), it doesn't need to be factored out. llvm-svn: 111715
2010-08-21 11:01:12 +08:00
LValue CodeGenFunction::EmitPredefinedLValue(const PredefinedExpr *E) {
Fix for bug http://llvm.org/PR17427. Assertion failed: "Computed __func__ length differs from type!" Reworked PredefinedExpr representation with internal StringLiteral field for function declaration. Differential Revision: http://reviews.llvm.org/D5365 llvm-svn: 219393
2014-10-09 16:45:04 +08:00
auto SL = E->getFunctionName();
assert(SL != nullptr && "No StringLiteral name in PredefinedExpr");
StringRef FnName = CurFn->getName();
if (FnName.startswith("\01"))
FnName = FnName.substr(1);
StringRef NameItems[] = {
PredefinedExpr::getIdentTypeName(E->getIdentType()), FnName};
std::string GVName = llvm::join(NameItems, NameItems + 2, ".");
This patch fixes couple of bugs for predefined expression used inside blocks. It fixes a crash in naming code for __func__ etc. when used in a block declared globally. It also brings back old naming convention for predefined expression which was broken. rdar://18961148 llvm-svn: 222065
2014-11-15 07:55:27 +08:00
if (CurCodeDecl && isa<BlockDecl>(CurCodeDecl)) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
auto C = CGM.GetAddrOfConstantCString(FnName, GVName.c_str());
return MakeAddrLValue(C, E->getType(), AlignmentSource::Decl);
This patch fixes couple of bugs for predefined expression used inside blocks. It fixes a crash in naming code for __func__ etc. when used in a block declared globally. It also brings back old naming convention for predefined expression which was broken. rdar://18961148 llvm-svn: 222065
2014-11-15 07:55:27 +08:00
}
Fix for bug http://llvm.org/PR17427. Assertion failed: "Computed __func__ length differs from type!" Reworked PredefinedExpr representation with internal StringLiteral field for function declaration. Differential Revision: http://reviews.llvm.org/D5365 llvm-svn: 219393
2014-10-09 16:45:04 +08:00
auto C = CGM.GetAddrOfConstantStringFromLiteral(SL, GVName);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(C, E->getType(), AlignmentSource::Decl);
Implement code generation for __func__, __FUNCTION__ and __PRETTY_FUNCTION__ llvm-svn: 40162
2007-07-21 13:21:51 +08:00
}
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
/// Emit a type description suitable for use by a runtime sanitizer library. The
/// format of a type descriptor is
///
/// \code
-fcatch-undefined-behavior: store the type name directly at the end of a type descriptor. 5% binary size reduction due to fewer relocations. llvm-svn: 165572
2012-10-10 07:55:19 +08:00
/// { i16 TypeKind, i16 TypeInfo }
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
/// \endcode
///
-fcatch-undefined-behavior: store the type name directly at the end of a type descriptor. 5% binary size reduction due to fewer relocations. llvm-svn: 165572
2012-10-10 07:55:19 +08:00
/// followed by an array of i8 containing the type name. TypeKind is 0 for an
/// integer, 1 for a floating point value, and -1 for anything else.
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
llvm::Constant *CodeGenFunction::EmitCheckTypeDescriptor(QualType T) {
ubsan: Only emit constants for filenames and type descriptors once. Produces neater IR in significantly less time. (~18% faster -O0 compile time for sqlite3 with -fsanitize=undefined) llvm-svn: 194231
2013-11-08 09:09:22 +08:00
// Only emit each type's descriptor once.
[MS-ABI] Implements MS-compatible RTTI Enables the emission of MS-compatible RTTI data structures for use with typeid, dynamic_cast and exceptions. Does not implement dynamic_cast or exceptions. As an artiface, typeid works in some cases but proper support an testing will coming in a subsequent patch. majnemer has fuzzed the results. Test cases included. Differential Revision: http://reviews.llvm.org/D3833 llvm-svn: 209523
2014-05-24 00:07:43 +08:00
if (llvm::Constant *C = CGM.getTypeDescriptorFromMap(T))
ubsan: Only emit constants for filenames and type descriptors once. Produces neater IR in significantly less time. (~18% faster -O0 compile time for sqlite3 with -fsanitize=undefined) llvm-svn: 194231
2013-11-08 09:09:22 +08:00
return C;
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
uint16_t TypeKind = -1;
uint16_t TypeInfo = 0;
if (T->isIntegerType()) {
TypeKind = 0;
TypeInfo = (llvm::Log2_32(getContext().getTypeSize(T)) << 1) |
Fixing a precedence issue with my previous commit. llvm-svn: 169041
2012-12-01 05:44:01 +08:00
(T->isSignedIntegerType() ? 1 : 0);
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
} else if (T->isFloatingType()) {
TypeKind = 1;
TypeInfo = getContext().getTypeSize(T);
}
// Format the type name as if for a diagnostic, including quotes and
// optionally an 'aka'.
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallString<32> Buffer;
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
CGM.getDiags().ConvertArgToString(DiagnosticsEngine::ak_qualtype,
(intptr_t)T.getAsOpaquePtr(),
Use StringRef to simplify code. No functional change. llvm-svn: 210751
2014-06-12 13:32:35 +08:00
StringRef(), StringRef(), None, Buffer,
Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or just letting them be implicitly created. llvm-svn: 216528
2014-08-27 14:28:36 +08:00
None);
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
llvm::Constant *Components[] = {
-fcatch-undefined-behavior: store the type name directly at the end of a type descriptor. 5% binary size reduction due to fewer relocations. llvm-svn: 165572
2012-10-10 07:55:19 +08:00
Builder.getInt16(TypeKind), Builder.getInt16(TypeInfo),
llvm::ConstantDataArray::getString(getLLVMContext(), Buffer)
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
};
llvm::Constant *Descriptor = llvm::ConstantStruct::getAnon(Components);
Ensure we preserve line information for each trap for -fcatch-undefined-behavior if we aren't optimizing. WIP. llvm-svn: 91382
2009-12-15 08:59:40 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *GV = new llvm::GlobalVariable(
CGM.getModule(), Descriptor->getType(),
/*isConstant=*/true, llvm::GlobalVariable::PrivateLinkage, Descriptor);
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
GV->setUnnamedAddr(true);
[Sanitizer] Introduce SanitizerMetadata class. It is responsible for generating metadata consumed by sanitizer instrumentation passes in the backend. Move several methods from CodeGenModule to SanitizerMetadata. For now the class is stateless, but soon it won't be the case. Instead of creating globals providing source-level information to ASan, we will create metadata nodes/strings which will be turned into actual global variables in the backend (if needed). No functionality change. llvm-svn: 214564
2014-08-02 05:35:28 +08:00
CGM.getSanitizerMetadata()->disableSanitizerForGlobal(GV);
ubsan: Only emit constants for filenames and type descriptors once. Produces neater IR in significantly less time. (~18% faster -O0 compile time for sqlite3 with -fsanitize=undefined) llvm-svn: 194231
2013-11-08 09:09:22 +08:00
// Remember the descriptor for this type.
[MS-ABI] Implements MS-compatible RTTI Enables the emission of MS-compatible RTTI data structures for use with typeid, dynamic_cast and exceptions. Does not implement dynamic_cast or exceptions. As an artiface, typeid works in some cases but proper support an testing will coming in a subsequent patch. majnemer has fuzzed the results. Test cases included. Differential Revision: http://reviews.llvm.org/D3833 llvm-svn: 209523
2014-05-24 00:07:43 +08:00
CGM.setTypeDescriptorInMap(T, GV);
ubsan: Only emit constants for filenames and type descriptors once. Produces neater IR in significantly less time. (~18% faster -O0 compile time for sqlite3 with -fsanitize=undefined) llvm-svn: 194231
2013-11-08 09:09:22 +08:00
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
return GV;
}
-fcatch-undefined-behavior: Factor emission of the creation of, and branch to, the trap BB out of the individual checks and into a common function, to prepare for making this code call into a runtime library. Rename the existing EmitCheck to EmitTypeCheck to clarify it and to move it out of the way of the new EmitCheck. llvm-svn: 163451
2012-09-08 10:08:36 +08:00
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
llvm::Value *CodeGenFunction::EmitCheckValue(llvm::Value *V) {
llvm::Type *TargetTy = IntPtrTy;
ubsan: Pass floating-point arguments to the runtime by value if they fit the value argument. If not, be sure we don't accidentally use a dynamic alloca. llvm-svn: 177690
2013-03-22 08:47:07 +08:00
// Floating-point types which fit into intptr_t are bitcast to integers
// and then passed directly (after zero-extension, if necessary).
if (V->getType()->isFloatingPointTy()) {
unsigned Bits = V->getType()->getPrimitiveSizeInBits();
if (Bits <= TargetTy->getIntegerBitWidth())
V = Builder.CreateBitCast(V, llvm::Type::getIntNTy(getLLVMContext(),
Bits));
}
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
// Integers which fit in intptr_t are zero-extended and passed directly.
if (V->getType()->isIntegerTy() &&
V->getType()->getIntegerBitWidth() <= TargetTy->getIntegerBitWidth())
return Builder.CreateZExt(V, TargetTy);
// Pointers are passed directly, everything else is passed by address.
if (!V->getType()->isPointerTy()) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Ptr = CreateDefaultAlignTempAlloca(V->getType());
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
Builder.CreateStore(V, Ptr);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
V = Ptr.getPointer();
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
}
return Builder.CreatePtrToInt(V, TargetTy);
}
/// \brief Emit a representation of a SourceLocation for passing to a handler
/// in a sanitizer runtime library. The format for this data is:
/// \code
/// struct SourceLocation {
/// const char *Filename;
/// int32_t Line, Column;
/// };
/// \endcode
/// For an invalid SourceLocation, the Filename pointer is null.
llvm::Constant *CodeGenFunction::EmitCheckSourceLocation(SourceLocation Loc) {
Make sure globals created by UBSan are not instrumented by ASan. Summary: This change adds description of globals created by UBSan instrumentation (UBSan handlers, type descriptors, filenames) to llvm.asan.globals metadata, effectively "blacklisting" them. This can dramatically decrease the data section in binaries built with UBSan+ASan, as UBSan tends to create a lot of handlers, and ASan instrumentation increases the global size to at least 64 bytes. Test Plan: clang regression test suite Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits, byoungyoung, kcc Differential Revision: http://reviews.llvm.org/D4575 llvm-svn: 213392
2014-07-19 01:50:06 +08:00
llvm::Constant *Filename;
int Line, Column;
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
PresumedLoc PLoc = getContext().getSourceManager().getPresumedLoc(Loc);
Make sure globals created by UBSan are not instrumented by ASan. Summary: This change adds description of globals created by UBSan instrumentation (UBSan handlers, type descriptors, filenames) to llvm.asan.globals metadata, effectively "blacklisting" them. This can dramatically decrease the data section in binaries built with UBSan+ASan, as UBSan tends to create a lot of handlers, and ASan instrumentation increases the global size to at least 64 bytes. Test Plan: clang regression test suite Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits, byoungyoung, kcc Differential Revision: http://reviews.llvm.org/D4575 llvm-svn: 213392
2014-07-19 01:50:06 +08:00
if (PLoc.isValid()) {
auto FilenameGV = CGM.GetAddrOfConstantCString(PLoc.getFilename(), ".src");
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CGM.getSanitizerMetadata()->disableSanitizerForGlobal(
cast<llvm::GlobalVariable>(FilenameGV.getPointer()));
Filename = FilenameGV.getPointer();
Make sure globals created by UBSan are not instrumented by ASan. Summary: This change adds description of globals created by UBSan instrumentation (UBSan handlers, type descriptors, filenames) to llvm.asan.globals metadata, effectively "blacklisting" them. This can dramatically decrease the data section in binaries built with UBSan+ASan, as UBSan tends to create a lot of handlers, and ASan instrumentation increases the global size to at least 64 bytes. Test Plan: clang regression test suite Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits, byoungyoung, kcc Differential Revision: http://reviews.llvm.org/D4575 llvm-svn: 213392
2014-07-19 01:50:06 +08:00
Line = PLoc.getLine();
Column = PLoc.getColumn();
} else {
Filename = llvm::Constant::getNullValue(Int8PtrTy);
Line = Column = 0;
}
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
Make sure globals created by UBSan are not instrumented by ASan. Summary: This change adds description of globals created by UBSan instrumentation (UBSan handlers, type descriptors, filenames) to llvm.asan.globals metadata, effectively "blacklisting" them. This can dramatically decrease the data section in binaries built with UBSan+ASan, as UBSan tends to create a lot of handlers, and ASan instrumentation increases the global size to at least 64 bytes. Test Plan: clang regression test suite Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits, byoungyoung, kcc Differential Revision: http://reviews.llvm.org/D4575 llvm-svn: 213392
2014-07-19 01:50:06 +08:00
llvm::Constant *Data[] = {Filename, Builder.getInt32(Line),
Builder.getInt32(Column)};
-fcatch-undefined-behavior: Factor emission of the creation of, and branch to, the trap BB out of the individual checks and into a common function, to prepare for making this code call into a runtime library. Rename the existing EmitCheck to EmitTypeCheck to clarify it and to move it out of the way of the new EmitCheck. llvm-svn: 163451
2012-09-08 10:08:36 +08:00
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
return llvm::ConstantStruct::getAnon(Data);
}
-fcatch-undefined-behavior: Factor emission of the creation of, and branch to, the trap BB out of the individual checks and into a common function, to prepare for making this code call into a runtime library. Rename the existing EmitCheck to EmitTypeCheck to clarify it and to move it out of the way of the new EmitCheck. llvm-svn: 163451
2012-09-08 10:08:36 +08:00
Propagate SanitizerKind into CodeGenFunction::EmitCheck() call. Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
2014-11-11 06:27:30 +08:00
namespace {
/// \brief Specify under what conditions this check can be recovered
enum class CheckRecoverableKind {
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
/// Always terminate program execution if this check fails.
Propagate SanitizerKind into CodeGenFunction::EmitCheck() call. Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
2014-11-11 06:27:30 +08:00
Unrecoverable,
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
/// Check supports recovering, runtime has both fatal (noreturn) and
/// non-fatal handlers for this check.
Propagate SanitizerKind into CodeGenFunction::EmitCheck() call. Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
2014-11-11 06:27:30 +08:00
Recoverable,
/// Runtime conditionally aborts, always need to support recovery.
AlwaysRecoverable
};
Revert r240270 ("Fixed/added namespace ending comments using clang-tidy"). llvm-svn: 240353
2015-06-23 07:07:51 +08:00
}
Propagate SanitizerKind into CodeGenFunction::EmitCheck() call. Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
2014-11-11 06:27:30 +08:00
Unify sanitizer kind representation between the driver and the rest of the compiler. No functional change. Differential Revision: http://reviews.llvm.org/D9618 llvm-svn: 237055
2015-05-12 05:39:14 +08:00
static CheckRecoverableKind getRecoverableKind(SanitizerMask Kind) {
assert(llvm::countPopulation(Kind) == 1);
Propagate SanitizerKind into CodeGenFunction::EmitCheck() call. Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
2014-11-11 06:27:30 +08:00
switch (Kind) {
case SanitizerKind::Vptr:
return CheckRecoverableKind::AlwaysRecoverable;
case SanitizerKind::Return:
case SanitizerKind::Unreachable:
return CheckRecoverableKind::Unrecoverable;
default:
return CheckRecoverableKind::Recoverable;
}
}
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
static void emitCheckHandlerCall(CodeGenFunction &CGF,
llvm::FunctionType *FnType,
ArrayRef<llvm::Value *> FnArgs,
StringRef CheckName,
CheckRecoverableKind RecoverKind, bool IsFatal,
llvm::BasicBlock *ContBB) {
assert(IsFatal || RecoverKind != CheckRecoverableKind::Unrecoverable);
bool NeedsAbortSuffix =
IsFatal && RecoverKind != CheckRecoverableKind::Unrecoverable;
std::string FnName = ("__ubsan_handle_" + CheckName +
(NeedsAbortSuffix ? "_abort" : "")).str();
bool MayReturn =
!IsFatal || RecoverKind == CheckRecoverableKind::AlwaysRecoverable;
llvm::AttrBuilder B;
if (!MayReturn) {
B.addAttribute(llvm::Attribute::NoReturn)
.addAttribute(llvm::Attribute::NoUnwind);
}
B.addAttribute(llvm::Attribute::UWTable);
llvm::Value *Fn = CGF.CGM.CreateRuntimeFunction(
FnType, FnName,
llvm::AttributeSet::get(CGF.getLLVMContext(),
llvm::AttributeSet::FunctionIndex, B));
llvm::CallInst *HandlerCall = CGF.EmitNounwindRuntimeCall(Fn, FnArgs);
if (!MayReturn) {
HandlerCall->setDoesNotReturn();
CGF.Builder.CreateUnreachable();
} else {
CGF.Builder.CreateBr(ContBB);
}
}
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
void CodeGenFunction::EmitCheck(
Unify sanitizer kind representation between the driver and the rest of the compiler. No functional change. Differential Revision: http://reviews.llvm.org/D9618 llvm-svn: 237055
2015-05-12 05:39:14 +08:00
ArrayRef<std::pair<llvm::Value *, SanitizerMask>> Checked,
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
StringRef CheckName, ArrayRef<llvm::Constant *> StaticArgs,
ArrayRef<llvm::Value *> DynamicArgs) {
[UBSan] Add !nosanitize metadata to the code generated by UBSan. This is used to mark the instructions emitted by Clang to implement variety of UBSan checks. Generally, we don't want to instrument these instructions with another sanitizers (like ASan). Reviewed in http://reviews.llvm.org/D4544 llvm-svn: 213291
2014-07-18 02:46:27 +08:00
assert(IsSanitizerScope);
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
assert(Checked.size() > 0);
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
llvm::Value *FatalCond = nullptr;
llvm::Value *RecoverableCond = nullptr;
Introduce -fsanitize-trap= flag. This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
2015-06-19 07:59:22 +08:00
llvm::Value *TrapCond = nullptr;
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
for (int i = 0, n = Checked.size(); i < n; ++i) {
llvm::Value *Check = Checked[i].first;
Introduce -fsanitize-trap= flag. This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
2015-06-19 07:59:22 +08:00
// -fsanitize-trap= overrides -fsanitize-recover=.
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
llvm::Value *&Cond =
Introduce -fsanitize-trap= flag. This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
2015-06-19 07:59:22 +08:00
CGM.getCodeGenOpts().SanitizeTrap.has(Checked[i].second)
? TrapCond
: CGM.getCodeGenOpts().SanitizeRecover.has(Checked[i].second)
? RecoverableCond
: FatalCond;
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
Cond = Cond ? Builder.CreateAnd(Cond, Check) : Check;
}
Introduce -fsanitize-trap= flag. This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
2015-06-19 07:59:22 +08:00
if (TrapCond)
EmitTrapCheck(TrapCond);
if (!FatalCond && !RecoverableCond)
return;
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
llvm::Value *JointCond;
if (FatalCond && RecoverableCond)
JointCond = Builder.CreateAnd(FatalCond, RecoverableCond);
else
JointCond = FatalCond ? FatalCond : RecoverableCond;
assert(JointCond);
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
CheckRecoverableKind RecoverKind = getRecoverableKind(Checked[0].second);
assert(SanOpts.has(Checked[0].second));
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
#ifndef NDEBUG
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
for (int i = 1, n = Checked.size(); i < n; ++i) {
assert(RecoverKind == getRecoverableKind(Checked[i].second) &&
Propagate SanitizerKind into CodeGenFunction::EmitCheck() call. Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
2014-11-11 06:27:30 +08:00
"All recoverable kinds in a single check must be same!");
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
assert(SanOpts.has(Checked[i].second));
}
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
#endif
[ubsan] Implement the -fcatch-undefined-behavior flag using a trapping implementation; this is much more inline with the original implementation (i.e., pre-ubsan) and does not require run-time library support. The trapping implementation can be invoked using either '-fcatch-undefined-behavior' or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed. llvm-svn: 173848
2013-01-30 07:31:22 +08:00
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
llvm::BasicBlock *Cont = createBasicBlock("cont");
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
llvm::BasicBlock *Handlers = createBasicBlock("handler." + CheckName);
llvm::Instruction *Branch = Builder.CreateCondBr(JointCond, Cont, Handlers);
[ubsan] Emit branch weight metadata to hint towards common case. Results in better block placement that helps close the performance gap when making ubsan checks recoverable. llvm-svn: 170263
2012-12-15 09:39:14 +08:00
// Give hint that we very much don't expect to execute the handler
// Value chosen to match UR_NONTAKEN_WEIGHT, see BranchProbabilityInfo.cpp
llvm::MDBuilder MDHelper(getLLVMContext());
llvm::MDNode *Node = MDHelper.createBranchWeights((1U << 20) - 1, 1);
Branch->setMetadata(llvm::LLVMContext::MD_prof, Node);
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
EmitBlock(Handlers);
[ubsan] Emit branch weight metadata to hint towards common case. Results in better block placement that helps close the performance gap when making ubsan checks recoverable. llvm-svn: 170263
2012-12-15 09:39:14 +08:00
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
// Emit handler arguments and create handler function type.
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
llvm::Constant *Info = llvm::ConstantStruct::getAnon(StaticArgs);
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *InfoPtr =
[ubsan] Make static check data non-const so it can be used for deduplication. llvm-svn: 171947
2013-01-09 11:39:41 +08:00
new llvm::GlobalVariable(CGM.getModule(), Info->getType(), false,
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
llvm::GlobalVariable::PrivateLinkage, Info);
InfoPtr->setUnnamedAddr(true);
[Sanitizer] Introduce SanitizerMetadata class. It is responsible for generating metadata consumed by sanitizer instrumentation passes in the backend. Move several methods from CodeGenModule to SanitizerMetadata. For now the class is stateless, but soon it won't be the case. Instead of creating globals providing source-level information to ASan, we will create metadata nodes/strings which will be turned into actual global variables in the backend (if needed). No functionality change. llvm-svn: 214564
2014-08-02 05:35:28 +08:00
CGM.getSanitizerMetadata()->disableSanitizerForGlobal(InfoPtr);
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVector<llvm::Value *, 4> Args;
SmallVector<llvm::Type *, 4> ArgTypes;
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
Args.reserve(DynamicArgs.size() + 1);
ArgTypes.reserve(DynamicArgs.size() + 1);
// Handler functions take an i8* pointing to the (handler-specific) static
// information block, followed by a sequence of intptr_t arguments
// representing operand values.
Args.push_back(Builder.CreateBitCast(InfoPtr, Int8PtrTy));
ArgTypes.push_back(Int8PtrTy);
for (size_t i = 0, n = DynamicArgs.size(); i != n; ++i) {
Args.push_back(EmitCheckValue(DynamicArgs[i]));
ArgTypes.push_back(IntPtrTy);
}
llvm::FunctionType *FnType =
llvm::FunctionType::get(CGM.VoidTy, ArgTypes, false);
[ubsan] Add flag to enable recovery from checks when possible. llvm-svn: 169114
2012-12-03 03:50:33 +08:00
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
if (!FatalCond || !RecoverableCond) {
// Simple case: we need to generate a single handler call, either
// fatal, or non-fatal.
emitCheckHandlerCall(*this, FnType, Args, CheckName, RecoverKind,
(FatalCond != nullptr), Cont);
-fcatch-undefined-behavior checking for appropriate vptr value: Clang CodeGen side. llvm-svn: 166661
2012-10-25 10:14:12 +08:00
} else {
Reimplement -fsanitize-recover family of flags. Introduce the following -fsanitize-recover flags: - -fsanitize-recover=<list>: Enable recovery for selected checks or group of checks. It is forbidden to explicitly list unrecoverable sanitizers here (that is, "address", "unreachable", "return"). - -fno-sanitize-recover=<list>: Disable recovery for selected checks or group of checks. - -f(no-)?sanitize-recover is now a synonym for -f(no-)?sanitize-recover=undefined,integer and will soon be deprecated. These flags are parsed left to right, and mask of "recoverable" sanitizer is updated accordingly, much like what we do for -fsanitize= flags. -fsanitize= and -fsanitize-recover= flag families are independent. CodeGen change: If there is a single UBSan handler function, responsible for implementing multiple checks, which have different recoverable setting, then we emit two handler calls instead of one: the first one for the set of "unrecoverable" checks, another one - for set of "recoverable" checks. If all checks implemented by a handler have the same recoverability setting, then the generated code will be the same. llvm-svn: 225719
2015-01-13 06:39:12 +08:00
// Emit two handler calls: first one for set of unrecoverable checks,
// another one for recoverable.
llvm::BasicBlock *NonFatalHandlerBB =
createBasicBlock("non_fatal." + CheckName);
llvm::BasicBlock *FatalHandlerBB = createBasicBlock("fatal." + CheckName);
Builder.CreateCondBr(FatalCond, NonFatalHandlerBB, FatalHandlerBB);
EmitBlock(FatalHandlerBB);
emitCheckHandlerCall(*this, FnType, Args, CheckName, RecoverKind, true,
NonFatalHandlerBB);
EmitBlock(NonFatalHandlerBB);
emitCheckHandlerCall(*this, FnType, Args, CheckName, RecoverKind, false,
Cont);
-fcatch-undefined-behavior checking for appropriate vptr value: Clang CodeGen side. llvm-svn: 166661
2012-10-25 10:14:12 +08:00
}
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
-fcatch-undefined-behavior: Factor emission of the creation of, and branch to, the trap BB out of the individual checks and into a common function, to prepare for making this code call into a runtime library. Rename the existing EmitCheck to EmitTypeCheck to clarify it and to move it out of the way of the new EmitCheck. llvm-svn: 163451
2012-09-08 10:08:36 +08:00
EmitBlock(Cont);
Implement runtime checks for undefined behavior. WIP. This implements a new flag -fcatch-undefined-behavior. The flag turns on additional runtime checks for: T a[I]; a[i] abort when i < 0 or i >= I. Future stuff includes shifts by >= bitwidth amounts. llvm-svn: 91198
2009-12-12 09:27:46 +08:00
}
[ubsan] Implement the -fcatch-undefined-behavior flag using a trapping implementation; this is much more inline with the original implementation (i.e., pre-ubsan) and does not require run-time library support. The trapping implementation can be invoked using either '-fcatch-undefined-behavior' or '-fsanitize=undefined-trap -fsanitize-undefined-trap-on-error', with the latter being preferred. Eventually, the -fcatch-undefined-behavior' flag will be removed. llvm-svn: 173848
2013-01-30 07:31:22 +08:00
void CodeGenFunction::EmitTrapCheck(llvm::Value *Checked) {
Split emission of -ftrapv checks and -fcatch-undefined-behavior checks into separate functions, since they share essentially no code. llvm-svn: 167259
2012-11-02 06:15:34 +08:00
llvm::BasicBlock *Cont = createBasicBlock("cont");
// If we're optimizing, collapse all calls to trap down to just one per
// function to save on code size.
if (!CGM.getCodeGenOpts().OptimizationLevel || !TrapBB) {
TrapBB = createBasicBlock("trap");
Builder.CreateCondBr(Checked, Cont, TrapBB);
EmitBlock(TrapBB);
Attach attribute "trap-func-name" to call sites of llvm.trap and llvm.debugtrap. This is needed to use clang's command line option "-ftrap-function" for LTO and enable changing the trap function name on a per-call-site basis. rdar://problem/21225723 Differential Revision: http://reviews.llvm.org/D10831 llvm-svn: 241306
2015-07-03 06:15:41 +08:00
llvm::CallInst *TrapCall = EmitTrapCall(llvm::Intrinsic::trap);
Split emission of -ftrapv checks and -fcatch-undefined-behavior checks into separate functions, since they share essentially no code. llvm-svn: 167259
2012-11-02 06:15:34 +08:00
TrapCall->setDoesNotReturn();
TrapCall->setDoesNotThrow();
Builder.CreateUnreachable();
} else {
Builder.CreateCondBr(Checked, Cont, TrapBB);
}
EmitBlock(Cont);
}
Attach attribute "trap-func-name" to call sites of llvm.trap and llvm.debugtrap. This is needed to use clang's command line option "-ftrap-function" for LTO and enable changing the trap function name on a per-call-site basis. rdar://problem/21225723 Differential Revision: http://reviews.llvm.org/D10831 llvm-svn: 241306
2015-07-03 06:15:41 +08:00
llvm::CallInst *CodeGenFunction::EmitTrapCall(llvm::Intrinsic::ID IntrID) {
Rely on default zero-arg value for IRBuilder::CreateCall calls to zero-arg functions Patch by servuswiegehtz at yahoo.de llvm-svn: 242168
2015-07-15 01:27:39 +08:00
llvm::CallInst *TrapCall = Builder.CreateCall(CGM.getIntrinsic(IntrID));
Attach attribute "trap-func-name" to call sites of llvm.trap and llvm.debugtrap. This is needed to use clang's command line option "-ftrap-function" for LTO and enable changing the trap function name on a per-call-site basis. rdar://problem/21225723 Differential Revision: http://reviews.llvm.org/D10831 llvm-svn: 241306
2015-07-03 06:15:41 +08:00
if (!CGM.getCodeGenOpts().TrapFuncName.empty())
TrapCall->addAttribute(llvm::AttributeSet::FunctionIndex,
"trap-func-name",
CGM.getCodeGenOpts().TrapFuncName);
return TrapCall;
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address CodeGenFunction::EmitArrayToPointerDecay(const Expr *E,
AlignmentSource *AlignSource) {
assert(E->getType()->isArrayType() &&
"Array to pointer decay must have array source type!");
// Expressions of array type can't be bitfields or vector elements.
LValue LV = EmitLValue(E);
Address Addr = LV.getAddress();
if (AlignSource) *AlignSource = LV.getAlignmentSource();
// If the array type was an incomplete type, we need to make sure
// the decay ends up being the right type.
llvm::Type *NewTy = ConvertType(E->getType());
Addr = Builder.CreateElementBitCast(Addr, NewTy);
// Note that VLA pointers are always decayed, so we don't need to do
// anything here.
if (!E->getType()->isVariableArrayType()) {
assert(isa<llvm::ArrayType>(Addr.getElementType()) &&
"Expected pointer to array");
Addr = Builder.CreateStructGEP(Addr, 0, CharUnits::Zero(), "arraydecay");
}
QualType EltType = E->getType()->castAsArrayTypeUnsafe()->getElementType();
return Builder.CreateElementBitCast(Addr, ConvertTypeForMem(EltType));
}
Implement rdar://7530813 - collapse multiple GEP instructions in IRgen This avoids generating two gep's for common array operations. Before we would generate something like: %tmp = load i32* %X.addr ; <i32> [#uses=1] %arraydecay = getelementptr inbounds [100 x i32]* %A, i32 0, i32 0 ; <i32*> [#uses=1] %arrayidx = getelementptr inbounds i32* %arraydecay, i32 %tmp ; <i32*> [#uses=1] %tmp1 = load i32* %arrayidx ; <i32> [#uses=1] Now we generate: %tmp = load i32* %X.addr ; <i32> [#uses=1] %arrayidx = getelementptr inbounds [100 x i32]* %A, i32 0, i32 %tmp ; <i32*> [#uses=1] %tmp1 = load i32* %arrayidx ; <i32> [#uses=1] Less IR is better at -O0. llvm-svn: 106966
2010-06-27 07:03:20 +08:00
/// isSimpleArrayDecayOperand - If the specified expr is a simple decay from an
/// array to pointer, return the array subexpression.
static const Expr *isSimpleArrayDecayOperand(const Expr *E) {
// If this isn't just an array->pointer decay, bail out.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *CE = dyn_cast<CastExpr>(E);
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
if (!CE || CE->getCastKind() != CK_ArrayToPointerDecay)
[C++11] Use 'nullptr'. llvm-svn: 210448
2014-06-09 10:04:02 +08:00
return nullptr;
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Implement rdar://7530813 - collapse multiple GEP instructions in IRgen This avoids generating two gep's for common array operations. Before we would generate something like: %tmp = load i32* %X.addr ; <i32> [#uses=1] %arraydecay = getelementptr inbounds [100 x i32]* %A, i32 0, i32 0 ; <i32*> [#uses=1] %arrayidx = getelementptr inbounds i32* %arraydecay, i32 %tmp ; <i32*> [#uses=1] %tmp1 = load i32* %arrayidx ; <i32> [#uses=1] Now we generate: %tmp = load i32* %X.addr ; <i32> [#uses=1] %arrayidx = getelementptr inbounds [100 x i32]* %A, i32 0, i32 %tmp ; <i32*> [#uses=1] %tmp1 = load i32* %arrayidx ; <i32> [#uses=1] Less IR is better at -O0. llvm-svn: 106966
2010-06-27 07:03:20 +08:00
// If this is a decay from variable width array, bail out.
const Expr *SubExpr = CE->getSubExpr();
if (SubExpr->getType()->isVariableArrayType())
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
return nullptr;
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Implement rdar://7530813 - collapse multiple GEP instructions in IRgen This avoids generating two gep's for common array operations. Before we would generate something like: %tmp = load i32* %X.addr ; <i32> [#uses=1] %arraydecay = getelementptr inbounds [100 x i32]* %A, i32 0, i32 0 ; <i32*> [#uses=1] %arrayidx = getelementptr inbounds i32* %arraydecay, i32 %tmp ; <i32*> [#uses=1] %tmp1 = load i32* %arrayidx ; <i32> [#uses=1] Now we generate: %tmp = load i32* %X.addr ; <i32> [#uses=1] %arrayidx = getelementptr inbounds [100 x i32]* %A, i32 0, i32 %tmp ; <i32*> [#uses=1] %tmp1 = load i32* %arrayidx ; <i32> [#uses=1] Less IR is better at -O0. llvm-svn: 106966
2010-06-27 07:03:20 +08:00
return SubExpr;
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
static llvm::Value *emitArraySubscriptGEP(CodeGenFunction &CGF,
llvm::Value *ptr,
ArrayRef<llvm::Value*> indices,
bool inbounds,
const llvm::Twine &name = "arrayidx") {
if (inbounds) {
return CGF.Builder.CreateInBoundsGEP(ptr, indices, name);
} else {
return CGF.Builder.CreateGEP(ptr, indices, name);
}
}
static CharUnits getArrayElementAlign(CharUnits arrayAlign,
llvm::Value *idx,
CharUnits eltSize) {
// If we have a constant index, we can use the exact offset of the
// element we're accessing.
if (auto constantIdx = dyn_cast<llvm::ConstantInt>(idx)) {
CharUnits offset = constantIdx->getZExtValue() * eltSize;
return arrayAlign.alignmentAtOffset(offset);
// Otherwise, use the worst-case alignment for any element.
} else {
return arrayAlign.alignmentOfArrayElement(eltSize);
}
}
static QualType getFixedSizeElementType(const ASTContext &ctx,
const VariableArrayType *vla) {
QualType eltType;
do {
eltType = vla->getElementType();
} while ((vla = ctx.getAsVariableArrayType(eltType)));
return eltType;
}
static Address emitArraySubscriptGEP(CodeGenFunction &CGF, Address addr,
ArrayRef<llvm::Value*> indices,
QualType eltType, bool inbounds,
const llvm::Twine &name = "arrayidx") {
// All the indices except that last must be zero.
#ifndef NDEBUG
for (auto idx : indices.drop_back())
assert(isa<llvm::ConstantInt>(idx) &&
cast<llvm::ConstantInt>(idx)->isZero());
#endif
// Determine the element size of the statically-sized base. This is
// the thing that the indices are expressed in terms of.
if (auto vla = CGF.getContext().getAsVariableArrayType(eltType)) {
eltType = getFixedSizeElementType(CGF.getContext(), vla);
}
// We can use that to compute the best alignment of the element.
CharUnits eltSize = CGF.getContext().getTypeSizeInChars(eltType);
CharUnits eltAlign =
getArrayElementAlign(addr.getAlignment(), indices.back(), eltSize);
llvm::Value *eltPtr =
emitArraySubscriptGEP(CGF, addr.getPointer(), indices, inbounds, name);
return Address(eltPtr, eltAlign);
}
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E,
bool Accessed) {
Modified ArraySubscriptExpr to have accessors getLHS and getRHS in addition to getBase and getIdx. getBase and getIdx now return a "normalized" view of the expression (e.g., always "A[4]" instead of possibly "4[A]"). getLHS and getRHS return the expressions with syntactic fidelity to the original source code. Also modified client code of ArraySubscriptExpr, including the AST dumper and pretty printer, the return-stack value checker, and the LLVM code generator. llvm-svn: 41180
2007-08-21 00:18:38 +08:00
// The index must always be an integer, which is not an aggregate. Emit it.
completely refactor codegen of scalar expressions out into its own CGExprScalar.cpp file. This patch temporarily breaks compound assignment operators, but greatly simplifies many things. llvm-svn: 41355
2007-08-24 13:35:26 +08:00
llvm::Value *Idx = EmitScalarExpr(E->getIdx());
PR4339: make sure to properly extend/trunc the index of a vector element insert/extract; the relevant instructions are defined to take only an i32. llvm-svn: 73005
2009-06-07 03:09:26 +08:00
QualType IdxTy = E->getIdx()->getType();
Introduce Type::isSignedIntegerOrEnumerationType() and Type::isUnsignedIntegerOrEnumerationType(), which are like Type::isSignedIntegerType() and Type::isUnsignedIntegerType() but also consider the underlying type of a C++0x scoped enumeration type. Audited all callers to the existing functions, switching those that need to also handle scoped enumeration types (e.g., those that deal with constant values) over to the new functions. Fixes PR9923 / <rdar://problem/9447851>. llvm-svn: 131735
2011-05-21 00:38:50 +08:00
bool IdxSigned = IdxTy->isSignedIntegerOrEnumerationType();
PR4339: make sure to properly extend/trunc the index of a vector element insert/extract; the relevant instructions are defined to take only an i32. llvm-svn: 73005
2009-06-07 03:09:26 +08:00
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
if (SanOpts.has(SanitizerKind::ArrayBounds))
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
EmitBoundsCheck(E, E->getBase(), Idx, IdxTy, Accessed);
Add support for codegen'ing vector subscripts, at least when they are lvalues. llvm-svn: 39724
2007-07-11 05:17:59 +08:00
// If the base is a vector type, then we are forming a vector element lvalue
// with this subscript.
ext_vector IRGen. Patch to allow indexing into ext_vector_type's 'hi/lo' components when used as lvalue. rdar://18031917 pr20697 llvm-svn: 215991
2014-08-20 01:17:40 +08:00
if (E->getBase()->getType()->isVectorType() &&
!isa<ExtVectorElementExpr>(E->getBase())) {
Add support for codegen'ing vector subscripts, at least when they are lvalues. llvm-svn: 39724
2007-07-11 05:17:59 +08:00
// Emit the vector as an lvalue to get its address.
Basic support for volatile loads and stores. Stores the volatile qualifier in the lvalue, and changes lvalue loads/stores to honor the volatile flag. Places which need some further attention are marked with FIXMEs. Patch by Cédric Venet. llvm-svn: 52264
2008-06-14 07:01:12 +08:00
LValue LHS = EmitLValue(E->getBase());
Modified ArraySubscriptExpr to have accessors getLHS and getRHS in addition to getBase and getIdx. getBase and getIdx now return a "normalized" view of the expression (e.g., always "A[4]" instead of possibly "4[A]"). getLHS and getRHS return the expressions with syntactic fidelity to the original source code. Also modified client code of ArraySubscriptExpr, including the AST dumper and pretty printer, the return-stack value checker, and the LLVM code generator. llvm-svn: 41180
2007-08-21 00:18:38 +08:00
assert(LHS.isSimple() && "Can only subscript lvalue vectors here!");
Basic support for volatile loads and stores. Stores the volatile qualifier in the lvalue, and changes lvalue loads/stores to honor the volatile flag. Places which need some further attention are marked with FIXMEs. Patch by Cédric Venet. llvm-svn: 52264
2008-06-14 07:01:12 +08:00
return LValue::MakeVectorElt(LHS.getAddress(), Idx,
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
E->getBase()->getType(),
LHS.getAlignmentSource());
Add support for codegen'ing vector subscripts, at least when they are lvalues. llvm-svn: 39724
2007-07-11 05:17:59 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// All the other cases basically behave like simple offsetting.
Modified ArraySubscriptExpr to have accessors getLHS and getRHS in addition to getBase and getIdx. getBase and getIdx now return a "normalized" view of the expression (e.g., always "A[4]" instead of possibly "4[A]"). getLHS and getRHS return the expressions with syntactic fidelity to the original source code. Also modified client code of ArraySubscriptExpr, including the AST dumper and pretty printer, the return-stack value checker, and the LLVM code generator. llvm-svn: 41180
2007-08-21 00:18:38 +08:00
// Extend or truncate the index type to 32 or 64-bits.
Assorted cleanup: - Have CGM precompute a number of commonly-used types - Have CGF copy that during initialization instead of recomputing them - Use TBAA info when initializing a parameter variable - Refactor the scalar ++/-- code llvm-svn: 125562
2011-02-15 17:22:45 +08:00
if (Idx->getType() != IntPtrTy)
Idx = Builder.CreateIntCast(Idx, IntPtrTy, IdxSigned, "idxprom");
Implement runtime checks for undefined behavior. WIP. This implements a new flag -fcatch-undefined-behavior. The flag turns on additional runtime checks for: T a[I]; a[i] abort when i < 0 or i >= I. Future stuff includes shifts by >= bitwidth amounts. llvm-svn: 91198
2009-12-12 09:27:46 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// Handle the extvector case we ignored above.
ext_vector IRGen. Patch to allow indexing into ext_vector_type's 'hi/lo' components when used as lvalue. rdar://18031917 pr20697 llvm-svn: 215991
2014-08-20 01:17:40 +08:00
if (isa<ExtVectorElementExpr>(E->getBase())) {
LValue LV = EmitLValue(E->getBase());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Addr = EmitExtVectorElementLValue(LV);
QualType EltType = LV.getType()->castAs<VectorType>()->getElementType();
Addr = emitArraySubscriptGEP(*this, Addr, Idx, EltType, /*inbounds*/ true);
return MakeAddrLValue(Addr, EltType, LV.getAlignmentSource());
}
AlignmentSource AlignSource;
Address Addr = Address::invalid();
if (const VariableArrayType *vla =
ext_vector IRGen. Patch to allow indexing into ext_vector_type's 'hi/lo' components when used as lvalue. rdar://18031917 pr20697 llvm-svn: 215991
2014-08-20 01:17:40 +08:00
getContext().getAsVariableArrayType(E->getType())) {
Change the IR-generation of VLAs so that we capture bounds, not sizes; so that we use well-typed allocas; and so that we properly recurse through the full set of variably-modified types. llvm-svn: 133827
2011-06-25 05:55:10 +08:00
// The base must be a pointer, which is not an aggregate. Emit
// it. It needs to be emitted first in case it's what captures
// the VLA bounds.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Addr = EmitPointerWithAlignment(E->getBase(), &AlignSource);
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Change the IR-generation of VLAs so that we capture bounds, not sizes; so that we use well-typed allocas; and so that we properly recurse through the full set of variably-modified types. llvm-svn: 133827
2011-06-25 05:55:10 +08:00
// The element count here is the total number of non-VLA elements.
llvm::Value *numElements = getVLASize(vla).first;
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Mark the multiply which occurs as part of performing pointer arithmetic on a VLA as 'nsw', per discussion with djg, and implement pointer arithmetic (other than array accesses) and pointer subtraction for VLA types. llvm-svn: 133855
2011-06-25 09:32:37 +08:00
// Effectively, the multiply by the VLA size is part of the GEP.
// GEP indexes are signed, and scaling an index isn't permitted to
// signed-overflow, so we use the same semantics for our explicit
// multiply. We suppress this if overflow is not undefined behavior.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (getLangOpts().isSignedOverflowDefined()) {
Mark the multiply which occurs as part of performing pointer arithmetic on a VLA as 'nsw', per discussion with djg, and implement pointer arithmetic (other than array accesses) and pointer subtraction for VLA types. llvm-svn: 133855
2011-06-25 09:32:37 +08:00
Idx = Builder.CreateMul(Idx, numElements);
} else {
Idx = Builder.CreateNSWMul(Idx, numElements);
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Addr = emitArraySubscriptGEP(*this, Addr, Idx, vla->getElementType(),
!getLangOpts().isSignedOverflowDefined());
Fix pointer addressing and array subscripting of Objective-C interface types. - I broke this in the switch to representing interfaces with opaque types. - <rdar://problem/6822660> clang crashes on subscript of interface in 32-bit mode llvm-svn: 70009
2009-04-25 13:08:32 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
} else if (const ObjCObjectType *OIT = E->getType()->getAs<ObjCObjectType>()){
// Indexing over an interface, as in "NSString *P; P[4];"
CharUnits InterfaceSize = getContext().getTypeSizeInChars(OIT);
llvm::Value *InterfaceSizeVal =
llvm::ConstantInt::get(Idx->getType(), InterfaceSize.getQuantity());;
llvm::Value *ScaledIdx = Builder.CreateMul(Idx, InterfaceSizeVal);
// Emit the base pointer.
Addr = EmitPointerWithAlignment(E->getBase(), &AlignSource);
// We don't necessarily build correct LLVM struct types for ObjC
// interfaces, so we can't rely on GEP to do this scaling
// correctly, so we need to cast to i8*. FIXME: is this actually
// true? A lot of other things in the fragile ABI would break...
llvm::Type *OrigBaseTy = Addr.getType();
Addr = Builder.CreateElementBitCast(Addr, Int8Ty);
// Do the GEP.
CharUnits EltAlign =
getArrayElementAlign(Addr.getAlignment(), Idx, InterfaceSize);
llvm::Value *EltPtr =
emitArraySubscriptGEP(*this, Addr.getPointer(), ScaledIdx, false);
Addr = Address(EltPtr, EltAlign);
// Cast back.
Addr = Builder.CreateBitCast(Addr, OrigBaseTy);
Implement rdar://7530813 - collapse multiple GEP instructions in IRgen This avoids generating two gep's for common array operations. Before we would generate something like: %tmp = load i32* %X.addr ; <i32> [#uses=1] %arraydecay = getelementptr inbounds [100 x i32]* %A, i32 0, i32 0 ; <i32*> [#uses=1] %arrayidx = getelementptr inbounds i32* %arraydecay, i32 %tmp ; <i32*> [#uses=1] %tmp1 = load i32* %arrayidx ; <i32> [#uses=1] Now we generate: %tmp = load i32* %X.addr ; <i32> [#uses=1] %arrayidx = getelementptr inbounds [100 x i32]* %A, i32 0, i32 %tmp ; <i32*> [#uses=1] %tmp1 = load i32* %arrayidx ; <i32> [#uses=1] Less IR is better at -O0. llvm-svn: 106966
2010-06-27 07:03:20 +08:00
} else if (const Expr *Array = isSimpleArrayDecayOperand(E->getBase())) {
// If this is A[i] where A is an array, the frontend will have decayed the
// base to be a ArrayToPointerDecay implicit cast. While correct, it is
// inefficient at -O0 to emit a "gep A, 0, 0" when codegen'ing it, then a
// "gep x, i" here. Emit one "gep A, 0, i".
assert(Array->getType()->isArrayType() &&
"Array to pointer decay must have array source type!");
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
LValue ArrayLV;
// For simple multidimensional array indexing, set the 'accessed' flag for
// better bounds-checking of the base expression.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *ASE = dyn_cast<ArraySubscriptExpr>(Array))
ubsan: Emit bounds checks for array indexing, vector indexing, and (in really simple cases) pointer arithmetic. This augments the existing bounds checking with language-level array bounds information. llvm-svn: 175949
2013-02-23 10:53:19 +08:00
ArrayLV = EmitArraySubscriptExpr(ASE, /*Accessed*/ true);
else
ArrayLV = EmitLValue(Array);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
IRgen: Reapply r128691 with a fix to ensure we don't increase alignment past that of the array element type. llvm-svn: 128698
2011-04-01 08:49:43 +08:00
// Propagate the alignment from the array itself to the result.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Addr = emitArraySubscriptGEP(*this, ArrayLV.getAddress(),
{CGM.getSize(CharUnits::Zero()), Idx},
E->getType(),
!getLangOpts().isSignedOverflowDefined());
AlignSource = ArrayLV.getAlignmentSource();
Fix pointer addressing and array subscripting of Objective-C interface types. - I broke this in the switch to representing interfaces with opaque types. - <rdar://problem/6822660> clang crashes on subscript of interface in 32-bit mode llvm-svn: 70009
2009-04-25 13:08:32 +08:00
} else {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// The base must be a pointer; emit it with an estimate of its alignment.
Addr = EmitPointerWithAlignment(E->getBase(), &AlignSource);
Addr = emitArraySubscriptGEP(*this, Addr, Idx, E->getType(),
!getLangOpts().isSignedOverflowDefined());
Handle VLA indexing llvm-svn: 61295
2008-12-21 08:11:23 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue LV = MakeAddrLValue(Addr, E->getType(), AlignSource);
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// TODO: Preserve/extend path TBAA metadata?
Refactor the representation of qualifiers to bring ExtQualType out of the Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our use of qualifiers and fix a few places that weren't dealing with qualifiers quite right; many more remain. llvm-svn: 82705
2009-09-25 03:53:00 +08:00
Simplify: replace getContext().getLangOpts() with just getLangOpts(). llvm-svn: 167261
2012-11-02 06:30:59 +08:00
if (getLangOpts().ObjC1 &&
getLangOpts().getGC() != LangOptions::NonGC) {
IRgen/LValue: Add LValue::setNonGC instead of SetObjCNonGC, for consistency with isNonGC(). llvm-svn: 111718
2010-08-21 11:22:38 +08:00
LV.setNonGC(!E->isOBJCGCCandidate(getContext()));
Starting patch to generate more specific API for objc's GC. Currently, new API will be generated under clang-cc's -fobjc-newgc-api flag which will eventually become the default. WIP. llvm-svn: 82082
2009-09-17 05:37:16 +08:00
setObjCGCLValueClass(getContext(), E, LV);
}
local array of objects are non-gc'able. llvm-svn: 65251
2009-02-22 07:37:19 +08:00
return LV;
Implement array subscripts for non-vla types. llvm-svn: 39622
2007-06-09 07:31:14 +08:00
}
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
LValue CodeGenFunction::EmitOMPArraySectionExpr(const OMPArraySectionExpr *E,
bool IsLowerBound) {
LValue Base;
if (auto *ASE =
dyn_cast<OMPArraySectionExpr>(E->getBase()->IgnoreParenImpCasts()))
Base = EmitOMPArraySectionExpr(ASE, IsLowerBound);
else
Base = EmitLValue(E->getBase());
QualType BaseTy = Base.getType();
llvm::Value *Idx = nullptr;
QualType ResultExprTy;
if (auto *AT = getContext().getAsArrayType(BaseTy))
ResultExprTy = AT->getElementType();
else
ResultExprTy = BaseTy->getPointeeType();
if (IsLowerBound || (!IsLowerBound && E->getColonLoc().isInvalid())) {
// Requesting lower bound or upper bound, but without provided length and
// without ':' symbol for the default length -> length = 1.
// Idx = LowerBound ?: 0;
if (auto *LowerBound = E->getLowerBound()) {
Idx = Builder.CreateIntCast(
EmitScalarExpr(LowerBound), IntPtrTy,
LowerBound->getType()->hasSignedIntegerRepresentation());
} else
Idx = llvm::ConstantInt::getNullValue(IntPtrTy);
} else {
// Try to emit length or lower bound as constant. If this is possible, 1 is
// subtracted from constant length or lower bound. Otherwise, emit LLVM IR
// (LB + Len) - 1.
auto &C = CGM.getContext();
auto *Length = E->getLength();
llvm::APSInt ConstLength;
if (Length) {
// Idx = LowerBound + Length - 1;
if (Length->isIntegerConstantExpr(ConstLength, C)) {
ConstLength = ConstLength.zextOrTrunc(PointerWidthInBits);
Length = nullptr;
}
auto *LowerBound = E->getLowerBound();
llvm::APSInt ConstLowerBound(PointerWidthInBits, /*isUnsigned=*/false);
if (LowerBound && LowerBound->isIntegerConstantExpr(ConstLowerBound, C)) {
ConstLowerBound = ConstLowerBound.zextOrTrunc(PointerWidthInBits);
LowerBound = nullptr;
}
if (!Length)
--ConstLength;
else if (!LowerBound)
--ConstLowerBound;
if (Length || LowerBound) {
auto *LowerBoundVal =
LowerBound
? Builder.CreateIntCast(
EmitScalarExpr(LowerBound), IntPtrTy,
LowerBound->getType()->hasSignedIntegerRepresentation())
: llvm::ConstantInt::get(IntPtrTy, ConstLowerBound);
auto *LengthVal =
Length
? Builder.CreateIntCast(
EmitScalarExpr(Length), IntPtrTy,
Length->getType()->hasSignedIntegerRepresentation())
: llvm::ConstantInt::get(IntPtrTy, ConstLength);
Idx = Builder.CreateAdd(LowerBoundVal, LengthVal, "lb_add_len",
/*HasNUW=*/false,
!getLangOpts().isSignedOverflowDefined());
if (Length && LowerBound) {
Idx = Builder.CreateSub(
Idx, llvm::ConstantInt::get(IntPtrTy, /*V=*/1), "idx_sub_1",
/*HasNUW=*/false, !getLangOpts().isSignedOverflowDefined());
}
} else
Idx = llvm::ConstantInt::get(IntPtrTy, ConstLength + ConstLowerBound);
} else {
// Idx = ArraySize - 1;
if (auto *VAT = C.getAsVariableArrayType(BaseTy)) {
Length = VAT->getSizeExpr();
if (Length->isIntegerConstantExpr(ConstLength, C))
Length = nullptr;
} else {
auto *CAT = C.getAsConstantArrayType(BaseTy);
ConstLength = CAT->getSize();
}
if (Length) {
auto *LengthVal = Builder.CreateIntCast(
EmitScalarExpr(Length), IntPtrTy,
Length->getType()->hasSignedIntegerRepresentation());
Idx = Builder.CreateSub(
LengthVal, llvm::ConstantInt::get(IntPtrTy, /*V=*/1), "len_sub_1",
/*HasNUW=*/false, !getLangOpts().isSignedOverflowDefined());
} else {
ConstLength = ConstLength.zextOrTrunc(PointerWidthInBits);
--ConstLength;
Idx = llvm::ConstantInt::get(IntPtrTy, ConstLength);
}
}
}
assert(Idx);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *EltPtr;
QualType FixedSizeEltType = ResultExprTy;
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
if (auto *VLA = getContext().getAsVariableArrayType(ResultExprTy)) {
// The element count here is the total number of non-VLA elements.
llvm::Value *numElements = getVLASize(VLA).first;
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
FixedSizeEltType = getFixedSizeElementType(getContext(), VLA);
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
// Effectively, the multiply by the VLA size is part of the GEP.
// GEP indexes are signed, and scaling an index isn't permitted to
// signed-overflow, so we use the same semantics for our explicit
// multiply. We suppress this if overflow is not undefined behavior.
if (getLangOpts().isSignedOverflowDefined()) {
Idx = Builder.CreateMul(Idx, numElements);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EltPtr = Builder.CreateGEP(Base.getPointer(), Idx, "arrayidx");
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
} else {
Idx = Builder.CreateNSWMul(Idx, numElements);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EltPtr = Builder.CreateInBoundsGEP(Base.getPointer(), Idx, "arrayidx");
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
}
} else if (BaseTy->isConstantArrayType()) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *ArrayPtr = Base.getPointer();
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
llvm::Value *Zero = llvm::ConstantInt::getNullValue(IntPtrTy);
llvm::Value *Args[] = {Zero, Idx};
if (getLangOpts().isSignedOverflowDefined())
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EltPtr = Builder.CreateGEP(ArrayPtr, Args, "arrayidx");
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
else
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EltPtr = Builder.CreateInBoundsGEP(ArrayPtr, Args, "arrayidx");
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
} else {
// The base must be a pointer, which is not an aggregate. Emit it.
if (getLangOpts().isSignedOverflowDefined())
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EltPtr = Builder.CreateGEP(Base.getPointer(), Idx, "arrayidx");
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
else
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EltPtr = Builder.CreateInBoundsGEP(Base.getPointer(), Idx, "arrayidx");
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits EltAlign =
Base.getAlignment().alignmentOfArrayElement(
getContext().getTypeSizeInChars(FixedSizeEltType));
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
// Limit the alignment to that of the result type.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue LV = MakeAddrLValue(Address(EltPtr, EltAlign), ResultExprTy,
Base.getAlignmentSource());
[OPENMP 4.0] Codegen for array sections. Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type). llvm-svn: 246422
2015-08-31 15:32:19 +08:00
LV.getQuals().setAddressSpace(BaseTy.getAddressSpace());
return LV;
}
add support for codegen of an OCUVectorComponent as an lvalue. We can now codegen: vec4.xy; as nothing! llvm-svn: 40769
2007-08-03 07:37:31 +08:00
LValue CodeGenFunction::
OCUVector -> ExtVector, shorthand for extended vector, per feedback from Chris. llvm-svn: 49942
2008-04-19 07:10:10 +08:00
EmitExtVectorElementExpr(const ExtVectorElementExpr *E) {
add support for codegen of an OCUVectorComponent as an lvalue. We can now codegen: vec4.xy; as nothing! llvm-svn: 40769
2007-08-03 07:37:31 +08:00
// Emit the base vector as an l-value.
enhance ExtVectorElementExpr to allow V->xxyy to work like (*V).xxyy llvm-svn: 64667
2009-02-17 05:11:58 +08:00
LValue Base;
// ExtVectorElementExpr's base can either be a vector or pointer to vector.
fix opencl extvector element extraction on rvalues. We previously error_unsupported on test10 and crashed on test11. llvm-svn: 92056
2009-12-24 05:31:11 +08:00
if (E->isArrow()) {
// If it is a pointer to a vector, emit the address and form an lvalue with
// it.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
AlignmentSource AlignSource;
Address Ptr = EmitPointerWithAlignment(E->getBase(), &AlignSource);
fix opencl extvector element extraction on rvalues. We previously error_unsupported on test10 and crashed on test11. llvm-svn: 92056
2009-12-24 05:31:11 +08:00
const PointerType *PT = E->getBase()->getType()->getAs<PointerType>();
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Base = MakeAddrLValue(Ptr, PT->getPointeeType(), AlignSource);
IRgen: Move remaining MakeAddr() calls to MakeAddrLValue(). llvm-svn: 111721
2010-08-21 11:44:13 +08:00
Base.getQuals().removeObjCGCAttr();
Switch a lot of call-sites over to using the new value-kind calculations. llvm-svn: 120084
2010-11-24 13:12:34 +08:00
} else if (E->getBase()->isGLValue()) {
fix opencl extvector element extraction on rvalues. We previously error_unsupported on test10 and crashed on test11. llvm-svn: 92056
2009-12-24 05:31:11 +08:00
// Otherwise, if the base is an lvalue ( as in the case of foo.x.x),
// emit the base as an lvalue.
assert(E->getBase()->getType()->isVectorType());
Base = EmitLValue(E->getBase());
} else {
// Otherwise, the base is a normal rvalue (as in (V+V).x), emit it as such.
Restore correct use of GC barriers. llvm-svn: 133144
2011-06-16 12:16:24 +08:00
assert(E->getBase()->getType()->isVectorType() &&
Fix -Asserts warning. llvm-svn: 92491
2010-01-05 02:02:28 +08:00
"Result must be a vector");
fix opencl extvector element extraction on rvalues. We previously error_unsupported on test10 and crashed on test11. llvm-svn: 92056
2009-12-24 05:31:11 +08:00
llvm::Value *Vec = EmitScalarExpr(E->getBase());
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
simplify my previous patch. llvm-svn: 92057
2009-12-24 05:33:41 +08:00
// Store the vector to memory (because LValue wants an address).
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address VecMem = CreateMemTemp(E->getBase()->getType());
fix opencl extvector element extraction on rvalues. We previously error_unsupported on test10 and crashed on test11. llvm-svn: 92056
2009-12-24 05:31:11 +08:00
Builder.CreateStore(Vec, VecMem);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Base = MakeAddrLValue(VecMem, E->getBase()->getType(),
AlignmentSource::Decl);
enhance ExtVectorElementExpr to allow V->xxyy to work like (*V).xxyy llvm-svn: 64667
2009-02-17 05:11:58 +08:00
}
Restore correct use of GC barriers. llvm-svn: 133144
2011-06-16 12:16:24 +08:00
QualType type =
E->getType().withCVRQualifiers(Base.getQuals().getCVRQualifiers());
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Remove AST dependency on VMCore by switching ExtVectorElementExpr off Constant. llvm-svn: 51068
2008-05-14 05:03:02 +08:00
// Encode the element access list into a vector of unsigned indices.
[CodeGen] Simplify creation of shuffle masks. No functional change intended. llvm-svn: 243439
2015-07-29 00:25:32 +08:00
SmallVector<uint32_t, 4> Indices;
Remove AST dependency on VMCore by switching ExtVectorElementExpr off Constant. llvm-svn: 51068
2008-05-14 05:03:02 +08:00
E->getEncodedElementAccess(Indices);
if (Base.isSimple()) {
[CodeGen] Simplify creation of shuffle masks. No functional change intended. llvm-svn: 243439
2015-07-29 00:25:32 +08:00
llvm::Constant *CV =
llvm::ConstantDataVector::get(getLLVMContext(), Indices);
Make sure we correctly set the alignment for vector loads and stores associated with vector element lvalues. Patch by Kevin Schoedel (with some minor modifications by me). llvm-svn: 153285
2012-03-23 06:36:39 +08:00
return LValue::MakeExtVectorElt(Base.getAddress(), CV, type,
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Base.getAlignmentSource());
Extend vector member references to include {.hi, .lo, .e, .o} which return a vector of the same element type and half the width, with the high, low, even, and odd elements respectively. Allow member references to member references, so that .hi.hi gives you the high quarter of a vector. This is fairly convenient syntax for some insert/extract operations. Remove some unnecessary methods/types in the ExtVectorElementExpr class. llvm-svn: 50892
2008-05-09 14:41:27 +08:00
}
Remove AST dependency on VMCore by switching ExtVectorElementExpr off Constant. llvm-svn: 51068
2008-05-14 05:03:02 +08:00
assert(Base.isExtVectorElt() && "Can only subscript lvalue vec elts here!");
llvm::Constant *BaseElts = Base.getExtVectorElts();
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
SmallVector<llvm::Constant *, 4> CElts;
add support for codegen of an OCUVectorComponent as an lvalue. We can now codegen: vec4.xy; as nothing! llvm-svn: 40769
2007-08-03 07:37:31 +08:00
Simplify code by using the new getAggregateElement method that got added recently. This also conveniently gets clang ready for a change about to land in mainline. llvm-svn: 149225
2012-01-30 14:20:36 +08:00
for (unsigned i = 0, e = Indices.size(); i != e; ++i)
CElts.push_back(BaseElts->getAggregateElement(Indices[i]));
update for ConstantVector API change. llvm-svn: 125538
2011-02-15 08:14:06 +08:00
llvm::Constant *CV = llvm::ConstantVector::get(CElts);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return LValue::MakeExtVectorElt(Base.getExtVectorAddress(), CV, type,
Base.getAlignmentSource());
add support for codegen of an OCUVectorComponent as an lvalue. We can now codegen: vec4.xy; as nothing! llvm-svn: 40769
2007-08-03 07:37:31 +08:00
}
Handle simple struct member expr. llvm-svn: 43258
2007-10-24 04:28:39 +08:00
LValue CodeGenFunction::EmitMemberExpr(const MemberExpr *E) {
Handle foo()->a = 42; llvm-svn: 43315
2007-10-25 06:26:28 +08:00
Expr *BaseExpr = E->getBase();
Basic support for volatile loads and stores. Stores the volatile qualifier in the lvalue, and changes lvalue loads/stores to honor the volatile flag. Places which need some further attention are marked with FIXMEs. Patch by Cédric Venet. llvm-svn: 52264
2008-06-14 07:01:12 +08:00
fix logic for member expr codegen. llvm-svn: 44520
2007-12-03 02:52:07 +08:00
// If this is s.x, emit s as an lvalue. If it is s->x, emit s as a scalar.
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
LValue BaseLV;
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
if (E->isArrow()) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
AlignmentSource AlignSource;
Address Addr = EmitPointerWithAlignment(BaseExpr, &AlignSource);
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
QualType PtrTy = BaseExpr->getType()->getPointeeType();
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EmitTypeCheck(TCK_MemberAccess, E->getExprLoc(), Addr.getPointer(), PtrTy);
BaseLV = MakeAddrLValue(Addr, PtrTy, AlignSource);
New -fcatch-undefined-behavior features: * when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check * check that references are bound to appropriate storage * check that 'this' has appropriate storage in member accesses and member function calls llvm-svn: 162523
2012-08-24 08:54:33 +08:00
} else
-fcatch-undefined-behavior: Factor emission of the creation of, and branch to, the trap BB out of the individual checks and into a common function, to prepare for making this code call into a runtime library. Rename the existing EmitCheck to EmitTypeCheck to clarify it and to move it out of the way of the new EmitCheck. llvm-svn: 163451
2012-09-08 10:08:36 +08:00
BaseLV = EmitCheckedLValue(BaseExpr, TCK_MemberAccess);
Handle simple struct member expr. llvm-svn: 43258
2007-10-24 04:28:39 +08:00
More LValue related code cleanup. llvm-svn: 86413
2009-11-08 07:06:58 +08:00
NamedDecl *ND = E->getMemberDecl();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (auto *Field = dyn_cast<FieldDecl>(ND)) {
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
LValue LV = EmitLValueForField(BaseLV, Field);
More LValue related code cleanup. llvm-svn: 86413
2009-11-08 07:06:58 +08:00
setObjCGCLValueClass(getContext(), E, LV);
return LV;
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (auto *VD = dyn_cast<VarDecl>(ND))
Handle member expressions where the member declaration is actually a static variable. Fixes PR5392. llvm-svn: 86414
2009-11-08 07:16:50 +08:00
return EmitGlobalVarDeclLValue(*this, E, VD);
Implement IRGen for MemberExpr referring to static member function. llvm-svn: 89938
2009-11-26 14:08:14 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *FD = dyn_cast<FunctionDecl>(ND))
Implement IRGen for MemberExpr referring to static member function. llvm-svn: 89938
2009-11-26 14:08:14 +08:00
return EmitFunctionDeclLValue(*this, E, FD);
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Unhandled member declaration!");
Expose the logic for field address codegen; it is needed for aggregate initializers, and I don't want to duplicate the bitfield-handling code. (I'll send a patch for aggregate initializers to the mailing list sometime soon.) llvm-svn: 46904
2008-02-09 16:50:58 +08:00
}
Handle simple struct member expr. llvm-svn: 43258
2007-10-24 04:28:39 +08:00
Correctly emit certain implicit references to 'self' even within a lambda. Bug #1 is that CGF's CurFuncDecl was "stuck" at lambda invocation functions. Fix that by generally improving getNonClosureContext to look through lambdas and captured statements but only report code contexts, which is generally what's wanted. Audit uses of CurFuncDecl and getNonClosureAncestor for correctness. Bug #2 is that lambdas weren't specially mapping 'self' when inside an ObjC method. Fix that by removing the requirement for that and using the normal EmitDeclRefLValue path in LoadObjCSelf. rdar://13800041 llvm-svn: 181000
2013-05-03 15:33:41 +08:00
/// Given that we are currently emitting a lambda, emit an l-value for
/// one of its members.
LValue CodeGenFunction::EmitLValueForLambdaField(const FieldDecl *Field) {
assert(cast<CXXMethodDecl>(CurCodeDecl)->getParent()->isLambda());
assert(cast<CXXMethodDecl>(CurCodeDecl)->getParent() == Field->getParent());
QualType LambdaTagType =
getContext().getTagDeclType(Field->getParent());
LValue LambdaLV = MakeNaturalAlignAddrLValue(CXXABIThisValue, LambdaTagType);
return EmitLValueForField(LambdaLV, Field);
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
/// Drill down to the storage of a field without walking into
/// reference types.
///
/// The resulting address doesn't necessarily have the right type.
static Address emitAddrOfFieldStorage(CodeGenFunction &CGF, Address base,
const FieldDecl *field) {
const RecordDecl *rec = field->getParent();
unsigned idx =
CGF.CGM.getTypes().getCGRecordLayout(rec).getLLVMFieldNo(field);
CharUnits offset;
// Adjust the alignment down to the given offset.
// As a special case, if the LLVM field index is 0, we know that this
// is zero.
assert((idx != 0 || CGF.getContext().getASTRecordLayout(rec)
.getFieldOffset(field->getFieldIndex()) == 0) &&
"LLVM field at index zero had non-zero offset?");
if (idx != 0) {
auto &recLayout = CGF.getContext().getASTRecordLayout(rec);
auto offsetInBits = recLayout.getFieldOffset(field->getFieldIndex());
offset = CGF.getContext().toCharUnitsFromBits(offsetInBits);
}
return CGF.Builder.CreateStructGEP(base, idx, offset, field->getName());
}
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
LValue CodeGenFunction::EmitLValueForField(LValue base,
const FieldDecl *field) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
AlignmentSource fieldAlignSource =
getFieldAlignmentSource(base.getAlignmentSource());
Propagate lvalue alignment into bitfields. Per report on cfe-dev. llvm-svn: 159295
2012-06-28 05:19:48 +08:00
if (field->isBitField()) {
const CGRecordLayout &RL =
CGM.getTypes().getCGRecordLayout(field->getParent());
const CGBitFieldInfo &Info = RL.getBitFieldInfo(field);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Addr = base.getAddress();
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
unsigned Idx = RL.getLLVMFieldNo(field);
if (Idx != 0)
// For structs, we GEP to the field that the record layout suggests.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Addr = Builder.CreateStructGEP(Addr, Idx, Info.StorageOffset,
field->getName());
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
// Get the access type.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Type *FieldIntTy =
llvm::Type::getIntNTy(getLLVMContext(), Info.StorageSize);
if (Addr.getElementType() != FieldIntTy)
Addr = Builder.CreateElementBitCast(Addr, FieldIntTy);
Rework the bitfield access IR generation to address PR13619 and generally support the C++11 memory model requirements for bitfield accesses by relying more heavily on LLVM's memory model. The primary change this introduces is to move from a manually aligned and strided access pattern across the bits of the bitfield to a much simpler lump access of all bits in the bitfield followed by math to extract the bits relevant for the particular field. This simplifies the code significantly, but relies on LLVM to intelligently lowering these integers. I have tested LLVM's lowering both synthetically and in benchmarks. The lowering appears to be functional, and there are no really significant performance regressions. Different code patterns accessing bitfields will vary in how this impacts them. The only real regressions I'm seeing are a few patterns where the LLVM code generation for loads that feed directly into a mask operation don't take advantage of the x86 ability to do a smaller load and a cheap zero-extension. This doesn't regress any benchmark in the nightly test suite on my box past the noise threshold, but my box is quite noisy. I'll be watching the LNT numbers, and will look into further improvements to the LLVM lowering as needed. llvm-svn: 169489
2012-12-06 19:14:44 +08:00
Propagate lvalue alignment into bitfields. Per report on cfe-dev. llvm-svn: 159295
2012-06-28 05:19:48 +08:00
QualType fieldType =
field->getType().withCVRQualifiers(base.getVRQualifiers());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return LValue::MakeBitfield(Addr, Info, fieldType, fieldAlignSource);
Propagate lvalue alignment into bitfields. Per report on cfe-dev. llvm-svn: 159295
2012-06-28 05:19:48 +08:00
}
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
const RecordDecl *rec = field->getParent();
QualType type = field->getType();
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
bool mayAlias = rec->hasAttr<MayAliasAttr>();
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address addr = base.getAddress();
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
unsigned cvr = base.getVRQualifiers();
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
bool TBAAPath = CGM.getCodeGenOpts().StructPathTBAA;
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
if (rec->isUnion()) {
change EmitLValueForField to cast the returned lvalue to the right type, even when in the struct case. This was one root issue that was causing type mismatches throughout the compiler. llvm-svn: 134862
2011-07-10 13:34:54 +08:00
// For unions, there is no pointer adjustment.
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
assert(!type->isReferenceType() && "union has reference member");
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
// TODO: handle path-aware TBAA for union.
TBAAPath = false;
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
} else {
// For structs, we GEP to the field that the record layout suggests.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
addr = emitAddrOfFieldStorage(*this, addr, field);
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
// If this is a reference field, load the reference right now.
if (const ReferenceType *refType = type->getAs<ReferenceType>()) {
llvm::LoadInst *load = Builder.CreateLoad(addr, "ref");
if (cvr & Qualifiers::Volatile) load->setVolatile(true);
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
// Loading the reference will disable path-aware TBAA.
TBAAPath = false;
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
if (CGM.shouldUseTBAA()) {
llvm::MDNode *tbaa;
if (mayAlias)
tbaa = CGM.getTBAAInfo(getContext().CharTy);
else
tbaa = CGM.getTBAAInfo(type);
TBAA: use the same format for scalar TBAA and struct-path aware TBAA. An updated version of r191586 with bug fix. Struct-path aware TBAA generates tags to specify the access path, while scalar TBAA only generates tags to scalar types. We should not generate a TBAA tag with null being the first field. When a TBAA type node is null, the tag should be null too. Make sure we don't decorate an instruction with a null TBAA tag. Added a testing case for the bug reported by Richard with -relaxed-aliasing and -fsanitizer=thread. llvm-svn: 192145
2013-10-08 08:08:49 +08:00
if (tbaa)
CGM.DecorateInstruction(load, tbaa);
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
mayAlias = false;
type = refType->getPointeeType();
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
CharUnits alignment =
getNaturalTypeAlignment(type, &fieldAlignSource, /*pointee*/ true);
addr = Address(load, alignment);
// Qualifiers on the struct don't apply to the referencee, and
// we'll pick up CVR from the actual type later, so reset these
// additional qualifiers now.
cvr = 0;
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
}
Codegen union member references. llvm-svn: 43390
2007-10-27 03:42:18 +08:00
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
change EmitLValueForField to cast the returned lvalue to the right type, even when in the struct case. This was one root issue that was causing type mismatches throughout the compiler. llvm-svn: 134862
2011-07-10 13:34:54 +08:00
// Make sure that the address is pointing to the right type. This is critical
// for both unions and structs. A union needs a bitcast, a struct element
// will need a bitcast if the LLVM type laid out doesn't match the desired
// type.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
addr = Builder.CreateElementBitCast(addr,
CGM.getTypes().ConvertTypeForMem(type),
field->getName());
Refactor the representation of qualifiers to bring ExtQualType out of the Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our use of qualifiers and fix a few places that weren't dealing with qualifiers quite right; many more remain. llvm-svn: 82705
2009-09-25 03:53:00 +08:00
Bring llvm.annotation* intrinsics support back to where it was in llvm-gcc: can annotate global, local variables, struct fields, or arbitrary statements (using the __builtin_annotation), rdar://8037476. llvm-svn: 139423
2011-09-10 06:41:49 +08:00
if (field->hasAttr<AnnotateAttr>())
addr = EmitFieldAnnotations(field, addr);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue LV = MakeAddrLValue(addr, type, fieldAlignSource);
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
LV.getQuals().addCVRQualifiers(cvr);
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
if (TBAAPath) {
const ASTRecordLayout &Layout =
getContext().getASTRecordLayout(field->getParent());
// Set the base type to be the base type of the base LValue and
// update offset to be relative to the base type.
Struct-path aware TBAA: fix handling of may_alias attribute. llvm-svn: 180656
2013-04-27 08:39:37 +08:00
LV.setTBAABaseType(mayAlias ? getContext().CharTy : base.getTBAABaseType());
LV.setTBAAOffset(mayAlias ? 0 : base.getTBAAOffset() +
Initial support for struct-path aware TBAA. Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to the actual type and 0, and are updated in EmitLValueForField. Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar. Added command line option -struct-path-tbaa. llvm-svn: 178797
2013-04-05 05:53:22 +08:00
Layout.getFieldOffset(field->getFieldIndex()) /
getContext().getCharWidth());
}
IRgen: Move remaining MakeAddr() calls to MakeAddrLValue(). llvm-svn: 111721
2010-08-21 11:44:13 +08:00
Miscellanous fixes in generatation of objc gc's write-barriers. llvm-svn: 82472
2009-09-22 02:54:29 +08:00
// __weak attribute on a field is ignored.
IRgen: Move remaining MakeAddr() calls to MakeAddrLValue(). llvm-svn: 111721
2010-08-21 11:44:13 +08:00
if (LV.getQuals().getObjCGCAttr() == Qualifiers::Weak)
LV.getQuals().removeObjCGCAttr();
Pretty up the emission of field l-values and use volatile and TBAA when loading references as part of that. Use 'char' TBAA when accessing (immediate!) fields of a may_alias struct; fixes PR9307. llvm-svn: 126540
2011-02-26 16:07:02 +08:00
// Fields of may_alias structs act like 'char' for TBAA purposes.
// FIXME: this should get propagated down through anonymous structs
// and unions.
if (mayAlias && LV.getTBAAInfo())
LV.setTBAAInfo(CGM.getTBAAInfo(getContext().CharTy));
IRgen: Move remaining MakeAddr() calls to MakeAddrLValue(). llvm-svn: 111721
2010-08-21 11:44:13 +08:00
return LV;
Handle simple struct member expr. llvm-svn: 43258
2007-10-24 04:28:39 +08:00
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
LValue
CodeGenFunction::EmitLValueForFieldInitialization(LValue Base,
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
const FieldDecl *Field) {
Add a new EmitLValueForFieldInitialization that will be used for initializing fields (and reference type fields in particular). llvm-svn: 94799
2010-01-29 13:24:29 +08:00
QualType FieldType = Field->getType();
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Add a new EmitLValueForFieldInitialization that will be used for initializing fields (and reference type fields in particular). llvm-svn: 94799
2010-01-29 13:24:29 +08:00
if (!FieldType->isReferenceType())
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
return EmitLValueForField(Base, Field);
Add a new EmitLValueForFieldInitialization that will be used for initializing fields (and reference type fields in particular). llvm-svn: 94799
2010-01-29 13:24:29 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address V = emitAddrOfFieldStorage(*this, Base.getAddress(), Field);
Add a new EmitLValueForFieldInitialization that will be used for initializing fields (and reference type fields in particular). llvm-svn: 94799
2010-01-29 13:24:29 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// Make sure that the address is pointing to the right type.
de-constify llvm::Type, patch by David Blaikie! llvm-svn: 135370
2011-07-18 12:24:23 +08:00
llvm::Type *llvmType = ConvertTypeForMem(FieldType);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
V = Builder.CreateElementBitCast(V, llvmType, Field->getName());
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
// TODO: access-path TBAA?
auto FieldAlignSource = getFieldAlignmentSource(Base.getAlignmentSource());
return MakeAddrLValue(V, FieldType, FieldAlignSource);
Add a new EmitLValueForFieldInitialization that will be used for initializing fields (and reference type fields in particular). llvm-svn: 94799
2010-01-29 13:24:29 +08:00
}
clean up some formatting. llvm-svn: 113129
2010-09-06 08:11:41 +08:00
LValue CodeGenFunction::EmitCompoundLiteralLValue(const CompoundLiteralExpr *E){
Use static storage duration for file-scope compound literals, even when they appear in non-constant initializers in C++. llvm-svn: 145087
2011-11-23 06:48:32 +08:00
if (E->isFileScope()) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
ConstantAddress GlobalPtr = CGM.GetAddrOfConstantCompoundLiteral(E);
return MakeAddrLValue(GlobalPtr, E->getType(), AlignmentSource::Decl);
Use static storage duration for file-scope compound literals, even when they appear in non-constant initializers in C++. llvm-svn: 145087
2011-11-23 06:48:32 +08:00
}
User better API for vla in compund literals. // rdar://11485774 llvm-svn: 158157
2012-06-08 02:15:55 +08:00
if (E->getType()->isVariablyModifiedType())
// make sure to emit the VLA size.
EmitVariablyModifiedType(E->getType());
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address DeclPtr = CreateMemTemp(E->getType(), ".compoundliteral");
clean up some formatting. llvm-svn: 113129
2010-09-06 08:11:41 +08:00
const Expr *InitExpr = E->getInitializer();
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue Result = MakeAddrLValue(DeclPtr, E->getType(), AlignmentSource::Decl);
Add codegen support for block-level compound literals. llvm-svn: 51081
2008-05-14 07:18:27 +08:00
Revert r153613 as it's causing large compile-time regressions on the nightly testers. llvm-svn: 153660
2012-03-30 01:37:10 +08:00
EmitAnyExprToMem(InitExpr, DeclPtr, E->getType().getQualifiers(),
/*Init*/ true);
Add codegen support for block-level compound literals. llvm-svn: 51081
2008-05-14 07:18:27 +08:00
return Result;
}
Implement IRGen for C++11's "T{1, 2, 3}", where T is an aggregate and the expression is treated as an lvalue. llvm-svn: 156781
2012-05-15 05:57:21 +08:00
LValue CodeGenFunction::EmitInitListLValue(const InitListExpr *E) {
if (!E->isGLValue())
// Initializing an aggregate temporary in C++11: T{...}.
return EmitAggExprToLValue(E);
// An lvalue initializer list must be initializing a reference.
assert(E->getNumInits() == 1 && "reference init with multiple values");
return EmitLValue(E->getInit(0));
}
Don't crash when emitting a glvalue conditional where one arm is a throw-expression. Based on a patch by Marius Wachtler! llvm-svn: 211388
2014-06-21 02:43:47 +08:00
/// Emit the operand of a glvalue conditional operator. This is either a glvalue
/// or a (possibly-parenthesized) throw-expression. If this is a throw, no
/// LValue is returned and the current block has been terminated.
static Optional<LValue> EmitLValueOrThrowExpression(CodeGenFunction &CGF,
const Expr *Operand) {
if (auto *ThrowExpr = dyn_cast<CXXThrowExpr>(Operand->IgnoreParens())) {
CGF.EmitCXXThrowExpr(ThrowExpr, /*KeepInsertionPoint*/false);
return None;
}
return CGF.EmitLValue(Operand);
}
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
LValue CodeGenFunction::
EmitConditionalOperatorLValue(const AbstractConditionalOperator *expr) {
if (!expr->isGLValue()) {
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
// ?: here should be an aggregate.
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
assert(hasAggregateEvaluationKind(expr->getType()) &&
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
"Unexpected conditional operator!");
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
return EmitAggExprToLValue(expr);
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
}
Some small improvements to dead code elimination; helps a bit on LLVM-Code-Symbols test. llvm-svn: 92152
2009-12-25 13:29:40 +08:00
Fix a crash for an edge case of the GNU ?: extension. llvm-svn: 148923
2012-01-25 13:04:17 +08:00
OpaqueValueMapping binding(*this, expr);
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
const Expr *condExpr = expr->getCond();
Change the interface to ConstantFoldsToSimpleInteger to not encode a bool + success into one tri-state integer, simplifying things. llvm-svn: 126592
2011-02-28 07:02:32 +08:00
bool CondExprBool;
if (ConstantFoldsToSimpleInteger(condExpr, CondExprBool)) {
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
const Expr *live = expr->getTrueExpr(), *dead = expr->getFalseExpr();
Change the interface to ConstantFoldsToSimpleInteger to not encode a bool + success into one tri-state integer, simplifying things. llvm-svn: 126592
2011-02-28 07:02:32 +08:00
if (!CondExprBool) std::swap(live, dead);
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
CodeGen: Initial instrumentation based PGO implementation llvm-svn: 198640
2014-01-07 06:27:43 +08:00
if (!ContainsLabel(dead)) {
CodeGen: Sentences end with a period llvm-svn: 198649
2014-01-07 08:20:28 +08:00
// If the true case is live, we need to track its region.
CodeGen: Initial instrumentation based PGO implementation llvm-svn: 198640
2014-01-07 06:27:43 +08:00
if (CondExprBool)
InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC) The RegionCounter type does a lot of legwork, but most of it is only meaningful within the implementation of CodeGenPGO. The uses elsewhere in CodeGen generally just want to increment or read counters, so do that directly. llvm-svn: 235664
2015-04-24 07:06:47 +08:00
incrementProfileCounter(expr);
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
return EmitLValue(live);
CodeGen: Initial instrumentation based PGO implementation llvm-svn: 198640
2014-01-07 06:27:43 +08:00
}
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
}
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
llvm::BasicBlock *lhsBlock = createBasicBlock("cond.true");
llvm::BasicBlock *rhsBlock = createBasicBlock("cond.false");
llvm::BasicBlock *contBlock = createBasicBlock("cond.end");
Better framework for conditional cleanups; untested as yet. I'm separately committing this because it incidentally changes some block orderings and minor IR issues, like using a phi instead of an unnecessary alloca. llvm-svn: 124277
2011-01-26 12:00:11 +08:00
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
ConditionalEvaluation eval(*this);
InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC) The RegionCounter type does a lot of legwork, but most of it is only meaningful within the implementation of CodeGenPGO. The uses elsewhere in CodeGen generally just want to increment or read counters, so do that directly. llvm-svn: 235664
2015-04-24 07:06:47 +08:00
EmitBranchOnBoolExpr(condExpr, lhsBlock, rhsBlock, getProfileCount(expr));
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
// Any temporaries created here are conditional.
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
EmitBlock(lhsBlock);
InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC) The RegionCounter type does a lot of legwork, but most of it is only meaningful within the implementation of CodeGenPGO. The uses elsewhere in CodeGen generally just want to increment or read counters, so do that directly. llvm-svn: 235664
2015-04-24 07:06:47 +08:00
incrementProfileCounter(expr);
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
eval.begin(*this);
Don't crash when emitting a glvalue conditional where one arm is a throw-expression. Based on a patch by Marius Wachtler! llvm-svn: 211388
2014-06-21 02:43:47 +08:00
Optional<LValue> lhs =
EmitLValueOrThrowExpression(*this, expr->getTrueExpr());
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
eval.end(*this);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Don't crash when emitting a glvalue conditional where one arm is a throw-expression. Based on a patch by Marius Wachtler! llvm-svn: 211388
2014-06-21 02:43:47 +08:00
if (lhs && !lhs->isSimple())
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
return EmitUnsupportedLValue(expr, "conditional operator");
Code generation of Conditional operators that are lvalues (but that aren't bitfields). llvm-svn: 81867
2009-09-16 00:35:24 +08:00
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
lhsBlock = Builder.GetInsertBlock();
Don't crash when emitting a glvalue conditional where one arm is a throw-expression. Based on a patch by Marius Wachtler! llvm-svn: 211388
2014-06-21 02:43:47 +08:00
if (lhs)
Builder.CreateBr(contBlock);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
// Any temporaries created here are conditional.
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
EmitBlock(rhsBlock);
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
eval.begin(*this);
Don't crash when emitting a glvalue conditional where one arm is a throw-expression. Based on a patch by Marius Wachtler! llvm-svn: 211388
2014-06-21 02:43:47 +08:00
Optional<LValue> rhs =
EmitLValueOrThrowExpression(*this, expr->getFalseExpr());
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
eval.end(*this);
Don't crash when emitting a glvalue conditional where one arm is a throw-expression. Based on a patch by Marius Wachtler! llvm-svn: 211388
2014-06-21 02:43:47 +08:00
if (rhs && !rhs->isSimple())
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
return EmitUnsupportedLValue(expr, "conditional operator");
rhsBlock = Builder.GetInsertBlock();
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
EmitBlock(contBlock);
Un-nest the meat of this function. llvm-svn: 124310
2011-01-27 03:21:13 +08:00
Don't crash when emitting a glvalue conditional where one arm is a throw-expression. Based on a patch by Marius Wachtler! llvm-svn: 211388
2014-06-21 02:43:47 +08:00
if (lhs && rhs) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::PHINode *phi = Builder.CreatePHI(lhs->getPointer()->getType(),
Don't crash when emitting a glvalue conditional where one arm is a throw-expression. Based on a patch by Marius Wachtler! llvm-svn: 211388
2014-06-21 02:43:47 +08:00
2, "cond-lvalue");
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
phi->addIncoming(lhs->getPointer(), lhsBlock);
phi->addIncoming(rhs->getPointer(), rhsBlock);
Address result(phi, std::min(lhs->getAlignment(), rhs->getAlignment()));
AlignmentSource alignSource =
std::max(lhs->getAlignmentSource(), rhs->getAlignmentSource());
return MakeAddrLValue(result, expr->getType(), alignSource);
Don't crash when emitting a glvalue conditional where one arm is a throw-expression. Based on a patch by Marius Wachtler! llvm-svn: 211388
2014-06-21 02:43:47 +08:00
} else {
assert((lhs || rhs) &&
"both operands of glvalue conditional are throw-expressions?");
return lhs ? *lhs : *rhs;
}
Support member reference on ?: of struct type. llvm-svn: 67603
2009-03-24 10:38:23 +08:00
}
Implement IRGen for C++11's "T{1, 2, 3}", where T is an aggregate and the expression is treated as an lvalue. llvm-svn: 156781
2012-05-15 05:57:21 +08:00
/// EmitCastLValue - Casts are never lvalues unless that cast is to a reference
/// type. If the cast is to a reference, we can have the usual lvalue result,
Implement most of dynamic_cast. WIP. llvm-svn: 88901
2009-11-16 14:50:58 +08:00
/// otherwise if a cast is needed by the code generator in an lvalue context,
/// then it must mean that we need the address of an aggregate in order to
Implement IRGen for C++11's "T{1, 2, 3}", where T is an aggregate and the expression is treated as an lvalue. llvm-svn: 156781
2012-05-15 05:57:21 +08:00
/// access one of its members. This can happen for all the reasons that casts
Implement most of dynamic_cast. WIP. llvm-svn: 88901
2009-11-16 14:50:58 +08:00
/// are permitted with aggregate result, including noop aggregate casts, and
/// cast from scalar to union.
add codegen support for casting an element to a union. There are some more complex cases (_Complex and structs) that I'm still working on. llvm-svn: 67218
2009-03-19 02:28:57 +08:00
LValue CodeGenFunction::EmitCastLValue(const CastExpr *E) {
Handle CK_DerivedToBase when emitting lvalue casts. llvm-svn: 81614
2009-09-13 00:16:49 +08:00
switch (E->getCastKind()) {
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_ToVoid:
case CK_BitCast:
case CK_ArrayToPointerDecay:
case CK_FunctionToPointerDecay:
case CK_NullToMemberPointer:
Introduce a null-to-pointer implicit cast kind. llvm-svn: 118966
2010-11-13 09:35:44 +08:00
case CK_NullToPointer:
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_IntegralToPointer:
case CK_PointerToIntegral:
Assorted work leading towards the elimination of CK_Unknown. llvm-svn: 119138
2010-11-15 17:13:47 +08:00
case CK_PointerToBoolean:
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_VectorSplat:
case CK_IntegralCast:
Assorted work leading towards the elimination of CK_Unknown. llvm-svn: 119138
2010-11-15 17:13:47 +08:00
case CK_IntegralToBoolean:
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_IntegralToFloating:
case CK_FloatingToIntegral:
Assorted work leading towards the elimination of CK_Unknown. llvm-svn: 119138
2010-11-15 17:13:47 +08:00
case CK_FloatingToBoolean:
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_FloatingCast:
Introduce five new cast kinds for various conversions into and between complex types. llvm-svn: 118994
2010-11-13 17:02:35 +08:00
case CK_FloatingRealToComplex:
Add a few more complex-related cast kinds that arise due to arbitrary implicit conversions; the last batch was specific to promotions. I think this is the full set we need. I do think dividing the cast kinds into floating and integral is probably a good idea. Annotate a *lot* more C casts with useful cast kinds. llvm-svn: 119036
2010-11-14 16:17:51 +08:00
case CK_FloatingComplexToReal:
case CK_FloatingComplexToBoolean:
Introduce five new cast kinds for various conversions into and between complex types. llvm-svn: 118994
2010-11-13 17:02:35 +08:00
case CK_FloatingComplexCast:
Add a few more complex-related cast kinds that arise due to arbitrary implicit conversions; the last batch was specific to promotions. I think this is the full set we need. I do think dividing the cast kinds into floating and integral is probably a good idea. Annotate a *lot* more C casts with useful cast kinds. llvm-svn: 119036
2010-11-14 16:17:51 +08:00
case CK_FloatingComplexToIntegralComplex:
Introduce five new cast kinds for various conversions into and between complex types. llvm-svn: 118994
2010-11-13 17:02:35 +08:00
case CK_IntegralRealToComplex:
Add a few more complex-related cast kinds that arise due to arbitrary implicit conversions; the last batch was specific to promotions. I think this is the full set we need. I do think dividing the cast kinds into floating and integral is probably a good idea. Annotate a *lot* more C casts with useful cast kinds. llvm-svn: 119036
2010-11-14 16:17:51 +08:00
case CK_IntegralComplexToReal:
case CK_IntegralComplexToBoolean:
Introduce five new cast kinds for various conversions into and between complex types. llvm-svn: 118994
2010-11-13 17:02:35 +08:00
case CK_IntegralComplexCast:
Add a few more complex-related cast kinds that arise due to arbitrary implicit conversions; the last batch was specific to promotions. I think this is the full set we need. I do think dividing the cast kinds into floating and integral is probably a good idea. Annotate a *lot* more C casts with useful cast kinds. llvm-svn: 119036
2010-11-14 16:17:51 +08:00
case CK_IntegralComplexToFloatingComplex:
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_DerivedToBaseMemberPointer:
case CK_BaseToDerivedMemberPointer:
case CK_MemberPointerToBoolean:
Split reinterpret_casts of member pointers out from CK_BitCast; this is general goodness because representations of member pointers are not always equivalent across member pointer types on all ABIs (even though this isn't really standard-endorsed). Take advantage of the new information to teach IR-generation how to do these reinterprets in constant initializers. Make sure this works when intermingled with hierarchy conversions (although this is not part of our motivating use case). Doing this in the constant-evaluator would probably have been better, but that would require a *lot* of extra structure in the representation of constant member pointers: you'd really have to track an arbitrary chain of hierarchy conversions and reinterpretations in order to get this right. Ultimately, this seems less complex. I also wasn't quite sure how to extend the constant evaluator to handle foldings that we don't actually want to treat as extended constant expressions. llvm-svn: 150551
2012-02-15 09:22:51 +08:00
case CK_ReinterpretMemberPointer:
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
case CK_AnyPointerToBlockPointerCast:
Rename the ARC cast kinds to start with "ARC". llvm-svn: 139466
2011-09-10 14:18:15 +08:00
case CK_ARCProduceObject:
case CK_ARCConsumeObject:
case CK_ARCReclaimReturnedObject:
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
case CK_ARCExtendBlockObject:
Delete dead code. llvm-svn: 185119
2013-06-28 08:23:34 +08:00
case CK_CopyAndAutoreleaseBlockObject:
Add front-end infrastructure now address space casts are in LLVM IR. With the introduction of explicit address space casts into LLVM, there's a need to provide a new cast kind the front-end can create for C/OpenCL/CUDA and code to produce address space casts from those kinds when appropriate. Patch by Michele Scandale! llvm-svn: 197036
2013-12-11 21:39:46 +08:00
case CK_AddressSpaceConversion:
Delete dead code. llvm-svn: 185119
2013-06-28 08:23:34 +08:00
return EmitUnsupportedLValue(E, "unexpected cast lvalue");
case CK_Dependent:
llvm_unreachable("dependent cast kind in IR gen!");
case CK_BuiltinFnToFnPtr:
llvm_unreachable("builtin functions are handled elsewhere");
Simplify atomic load/store IRGen. Also fixes a couple minor bugs along the way; see testcases. llvm-svn: 186049
2013-07-11 09:32:21 +08:00
// These are never l-values; just use the aggregate emission code.
Delete dead code. llvm-svn: 185119
2013-06-28 08:23:34 +08:00
case CK_NonAtomicToAtomic:
case CK_AtomicToNonAtomic:
Simplify atomic load/store IRGen. Also fixes a couple minor bugs along the way; see testcases. llvm-svn: 186049
2013-07-11 09:32:21 +08:00
return EmitAggExprToLValue(E);
Some minor cleanup for EmitCastLValue. llvm-svn: 88894
2009-11-16 13:48:01 +08:00
Remove CK_DynamicToNull. llvm-svn: 129265
2011-04-11 10:03:26 +08:00
case CK_Dynamic: {
Implement most of dynamic_cast. WIP. llvm-svn: 88901
2009-11-16 14:50:58 +08:00
LValue LV = EmitLValue(E->getSubExpr());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address V = LV.getAddress();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *DCE = cast<CXXDynamicCastExpr>(E);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeNaturalAlignAddrLValue(EmitDynamicCast(V, DCE), E->getType());
Implement most of dynamic_cast. WIP. llvm-svn: 88901
2009-11-16 14:50:58 +08:00
}
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_ConstructorConversion:
case CK_UserDefinedConversion:
Give conversions of block pointers to ObjC pointers a different cast kind than conversions of C pointers to ObjC pointers. In order to ensure that we've caught every case, add asserts to CastExpr that strictly determine which cast kind is used for which kind of bit cast. llvm-svn: 139352
2011-09-09 13:25:32 +08:00
case CK_CPointerToObjCPointerCast:
case CK_BlockPointerToObjCPointerCast:
Delete dead code. llvm-svn: 185119
2013-06-28 08:23:34 +08:00
case CK_NoOp:
case CK_LValueToRValue:
add codegen support for casting an element to a union. There are some more complex cases (_Complex and structs) that I'm still working on. llvm-svn: 67218
2009-03-19 02:28:57 +08:00
return EmitLValue(E->getSubExpr());
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_UncheckedDerivedToBase:
case CK_DerivedToBase: {
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
const RecordType *DerivedClassTy =
Handle CK_DerivedToBase when emitting lvalue casts. llvm-svn: 81614
2009-09-13 00:16:49 +08:00
E->getSubExpr()->getType()->getAs<RecordType>();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *DerivedClassDecl = cast<CXXRecordDecl>(DerivedClassTy->getDecl());
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Handle CK_DerivedToBase when emitting lvalue casts. llvm-svn: 81614
2009-09-13 00:16:49 +08:00
LValue LV = EmitLValue(E->getSubExpr());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address This = LV.getAddress();
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Handle CK_DerivedToBase when emitting lvalue casts. llvm-svn: 81614
2009-09-13 00:16:49 +08:00
// Perform the derived-to-base conversion
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Base = GetAddressOfBaseClass(
Sanitize upcasts and conversion to virtual base. This change adds UBSan check to upcasts. Namely, when we perform derived-to-base conversion, we: 1) check that the pointer-to-derived has suitable alignment and underlying storage, if this pointer is non-null. 2) if vptr-sanitizer is enabled, and we perform conversion to virtual base, we check that pointer-to-derived has a matching vptr. llvm-svn: 219642
2014-10-14 07:59:00 +08:00
This, DerivedClassDecl, E->path_begin(), E->path_end(),
/*NullCheckValue=*/false, E->getExprLoc());
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(Base, E->getType(), LV.getAlignmentSource());
Handle CK_DerivedToBase when emitting lvalue casts. llvm-svn: 81614
2009-09-13 00:16:49 +08:00
}
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_ToUnion:
IRgen: A few more ConvertType cleanups. llvm-svn: 95423
2010-02-06 04:02:42 +08:00
return EmitAggExprToLValue(E);
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_BaseToDerived: {
Handle base-to-derived casts. Will land test case shortly. llvm-svn: 89678
2009-11-24 01:57:54 +08:00
const RecordType *DerivedClassTy = E->getType()->getAs<RecordType>();
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
auto *DerivedClassDecl = cast<CXXRecordDecl>(DerivedClassTy->getDecl());
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Handle base-to-derived casts. Will land test case shortly. llvm-svn: 89678
2009-11-24 01:57:54 +08:00
LValue LV = EmitLValue(E->getSubExpr());
ubsan: Add checking for invalid downcasts. Per [expr.static.cast]p2 and p11, base-to-derived casts have undefined behavior if the object is not actually an instance of the derived type. llvm-svn: 175078
2013-02-14 05:18:23 +08:00
Handle base-to-derived casts. Will land test case shortly. llvm-svn: 89678
2009-11-24 01:57:54 +08:00
// Perform the base-to-derived conversion
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address Derived =
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
GetAddressOfDerivedClass(LV.getAddress(), DerivedClassDecl,
Store inheritance paths after CastExprs instead of inside them. This takes some trickery since CastExpr has subclasses (and indeed, is abstract). Also, smoosh the CastKind into the bitfield from Expr. Drops two words of storage from Expr in the common case of expressions which don't need inheritance paths. Avoids a separate allocation and another word of overhead in cases needing inheritance paths. Also has the advantage of not leaking memory, since destructors for AST nodes are never run. llvm-svn: 110507
2010-08-07 14:22:56 +08:00
E->path_begin(), E->path_end(),
/*NullCheckValue=*/false);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
UBSan: Fix alignment checks emitted in downcasts. Summary: UBSan was checking for alignment of the derived class on the pointer to the base class, before converting. With some class hierarchies, this could generate false positives. Added test-case. llvm-svn: 187948
2013-08-08 09:08:17 +08:00
// C++11 [expr.static.cast]p2: Behavior is undefined if a downcast is
// performed and the object is not of the derived type.
[Sanitizer] Remove brittle cache variable and slightly simplify blacklisting code. Now CodeGenFunction is responsible for looking at sanitizer blacklist (in CodeGenFunction::StartFunction) and turning off instrumentation, if necessary. No functionality change. llvm-svn: 212501
2014-07-08 07:59:57 +08:00
if (sanitizePerformTypeCheck())
UBSan: Fix alignment checks emitted in downcasts. Summary: UBSan was checking for alignment of the derived class on the pointer to the base class, before converting. With some class hierarchies, this could generate false positives. Added test-case. llvm-svn: 187948
2013-08-08 09:08:17 +08:00
EmitTypeCheck(TCK_DowncastReference, E->getExprLoc(),
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Derived.getPointer(), E->getType());
UBSan: Fix alignment checks emitted in downcasts. Summary: UBSan was checking for alignment of the derived class on the pointer to the base class, before converting. With some class hierarchies, this could generate false positives. Added test-case. llvm-svn: 187948
2013-08-08 09:08:17 +08:00
Implement bad cast checks using control flow integrity information. This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class. Differential Revision: http://reviews.llvm.org/D8312 llvm-svn: 232241
2015-03-14 10:42:25 +08:00
if (SanOpts.has(SanitizerKind::CFIDerivedCast))
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EmitVTablePtrCheckForCast(E->getType(), Derived.getPointer(),
/*MayBeNull=*/false,
Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag. This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 llvm-svn: 240109
2015-06-19 09:51:54 +08:00
CFITCK_DerivedCast, E->getLocStart());
Implement bad cast checks using control flow integrity information. This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class. Differential Revision: http://reviews.llvm.org/D8312 llvm-svn: 232241
2015-03-14 10:42:25 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(Derived, E->getType(), LV.getAlignmentSource());
Some minor cleanup for EmitCastLValue. llvm-svn: 88894
2009-11-16 13:48:01 +08:00
}
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_LValueBitCast: {
Some minor cleanup for EmitCastLValue. llvm-svn: 88894
2009-11-16 13:48:01 +08:00
// This must be a reinterpret_cast (or c-style equivalent).
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *CE = cast<ExplicitCastExpr>(E);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Handle CK_BitCast in EmitCastLValue. llvm-svn: 88810
2009-11-15 05:21:42 +08:00
LValue LV = EmitLValue(E->getSubExpr());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address V = Builder.CreateBitCast(LV.getAddress(),
ConvertType(CE->getTypeAsWritten()));
Implement bad cast checks using control flow integrity information. This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class. Differential Revision: http://reviews.llvm.org/D8312 llvm-svn: 232241
2015-03-14 10:42:25 +08:00
if (SanOpts.has(SanitizerKind::CFIUnrelatedCast))
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EmitVTablePtrCheckForCast(E->getType(), V.getPointer(),
/*MayBeNull=*/false,
Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag. This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 llvm-svn: 240109
2015-06-19 09:51:54 +08:00
CFITCK_UnrelatedCast, E->getLocStart());
Implement bad cast checks using control flow integrity information. This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class. Differential Revision: http://reviews.llvm.org/D8312 llvm-svn: 232241
2015-03-14 10:42:25 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(V, E->getType(), LV.getAlignmentSource());
Handle CK_BitCast in EmitCastLValue. llvm-svn: 88810
2009-11-15 05:21:42 +08:00
}
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
case CK_ObjCObjectLValueCast: {
Allow reference binding of a reference of Objective-C object type to an lvalue of another, compatible Objective-C object type (e.g., a subclass). Introduce a new initialization sequence step kind to describe this binding, along with a new cast kind. Fixes PR7741. llvm-svn: 110513
2010-08-07 19:51:51 +08:00
LValue LV = EmitLValue(E->getSubExpr());
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address V = Builder.CreateElementBitCast(LV.getAddress(),
ConvertType(E->getType()));
return MakeAddrLValue(V, E->getType(), LV.getAlignmentSource());
Allow reference binding of a reference of Objective-C object type to an lvalue of another, compatible Objective-C object type (e.g., a subclass). Introduce a new initialization sequence step kind to describe this binding, along with a new cast kind. Fixes PR7741. llvm-svn: 110513
2010-08-07 19:51:51 +08:00
}
Implement OpenCL event_t as Clang builtin type, including event_t related OpenCL restrictions (OpenCL 1.2 spec 6.9) llvm-svn: 172973
2013-01-20 20:31:11 +08:00
case CK_ZeroToOCLEvent:
llvm_unreachable("NULL to OpenCL event lvalue cast is not valid");
Handle CK_DerivedToBase when emitting lvalue casts. llvm-svn: 81614
2009-09-13 00:16:49 +08:00
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Reinstate the scalar-cast-to-const-reference improvements, this time with the proper spelling of "non-class prvalue". Silly me, I think class rvalues were xvalues rather than prvalues! Hah hah hah. llvm-svn: 108443
2010-07-16 02:58:16 +08:00
llvm_unreachable("Unhandled lvalue cast kind?");
add codegen support for casting an element to a union. There are some more complex cases (_Complex and structs) that I'm still working on. llvm-svn: 67218
2009-03-19 02:28:57 +08:00
}
Save a copy expression for non-trivial copy constructions of catch variables. llvm-svn: 125661
2011-02-16 16:02:54 +08:00
LValue CodeGenFunction::EmitOpaqueValueLValue(const OpaqueValueExpr *e) {
Bind function "r-values" as l-values when emitting them as opaque values. Silly C type system. llvm-svn: 144144
2011-11-09 06:54:08 +08:00
assert(OpaqueValueMappingData::shouldBindAsLValue(e));
Change the representation of GNU ?: expressions to use a different expression class and to bind the shared value using OpaqueValueExpr. This fixes an unnoticed problem with deserialization of these expressions where the deserialized form would lose the vital pointer-equality trait; or rather, it fixes it because this patch also does the right thing for deserializing OVEs. Change OVEs to not be a "temporary object" in the sense that copy elision is permitted. This new representation is not totally unawkward to work with, but I think that's really part and parcel with the semantics we're modelling here. In particular, it's much easier to fix things like the copy elision bug and to make the CFG look right. I've tried to update the analyzer to deal with this in at least some obvious cases, and I think we get a much better CFG out, but the printing of OpaqueValueExprs probably needs some work. llvm-svn: 125744
2011-02-17 18:25:35 +08:00
return getOpaqueLValueMapping(e);
Save a copy expression for non-trivial copy constructions of catch variables. llvm-svn: 125661
2011-02-16 16:02:54 +08:00
}
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
RValue CodeGenFunction::EmitRValueForField(LValue LV,
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
const FieldDecl *FD,
SourceLocation Loc) {
Step forward with supporting of ARM homogenous aggregates: - Handle unions - Handle C++ classes llvm-svn: 154664
2012-04-13 19:22:00 +08:00
QualType FT = FD->getType();
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
LValue FieldLV = EmitLValueForField(LV, FD);
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
switch (getEvaluationKind(FT)) {
case TEK_Complex:
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
return RValue::getComplex(EmitLoadOfComplex(FieldLV, Loc));
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
case TEK_Aggregate:
Propagate alignment on lvalues through EmitLValueForField. PR12395. llvm-svn: 154789
2012-04-16 11:54:45 +08:00
return FieldLV.asAggregateRValue();
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
case TEK_Scalar:
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
return EmitLoadOfLValue(FieldLV, Loc);
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
}
llvm_unreachable("bad evaluation kind");
Step forward with supporting of ARM homogenous aggregates: - Handle unions - Handle C++ classes llvm-svn: 154664
2012-04-13 19:22:00 +08:00
}
Introduce a new AST node describing reference binding to temporaries. MaterializeTemporaryExpr captures a reference binding to a temporary value, making explicit that the temporary value (a prvalue) needs to be materialized into memory so that its address can be used. The intended AST invariant here is that a reference will always bind to a glvalue, and MaterializeTemporaryExpr will be used to convert prvalues into glvalues for that binding to happen. For example, given const int& r = 1.0; The initializer of "r" will be a MaterializeTemporaryExpr whose subexpression is an implicit conversion from the double literal "1.0" to an integer value. IR generation benefits most from this new node, since it was previously guessing (badly) when to materialize temporaries for the purposes of reference binding. There are likely more refactoring and cleanups we could perform there, but the introduction of MaterializeTemporaryExpr fixes PR9565, a case where IR generation would effectively bind a const reference directly to a bitfield in a struct. Addresses <rdar://problem/9552231>. llvm-svn: 133521
2011-06-22 01:03:29 +08:00
split stmt/expr codegen into their own files. llvm-svn: 39540
2007-06-02 02:02:12 +08:00
//===--------------------------------------------------------------------===//
// Expression Emission
//===--------------------------------------------------------------------===//
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
RValue CodeGenFunction::EmitCallExpr(const CallExpr *E,
Fill in the return value slot in CGExprAgg::VisitCallExpr. This takes us halfway towards fixing PR5824. llvm-svn: 92142
2009-12-25 04:40:36 +08:00
ReturnValueSlot ReturnValue) {
Set call attribute for direct calls (i.e. noreturn). - Remove an unused variant of EmitCallExpr overload. llvm-svn: 65130
2009-02-21 02:06:48 +08:00
// Builtins never have block type.
if (E->getCallee()->getType()->isBlockPointerType())
Pass the return value slot to all call exprs. llvm-svn: 92145
2009-12-25 05:13:40 +08:00
return EmitBlockCallExpr(E, ReturnValue);
Set call attribute for direct calls (i.e. noreturn). - Remove an unused variant of EmitCallExpr overload. llvm-svn: 65130
2009-02-21 02:06:48 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *CE = dyn_cast<CXXMemberCallExpr>(E))
Pass the return value slot to all call exprs. llvm-svn: 92145
2009-12-25 05:13:40 +08:00
return EmitCXXMemberCallExpr(CE, ReturnValue);
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *CE = dyn_cast<CUDAKernelCallExpr>(E))
CUDA: IR generation support for kernel call expressions llvm-svn: 141300
2011-10-07 02:29:37 +08:00
return EmitCUDAKernelCallExpr(CE, ReturnValue);
When extracting the callee declaration from a call expression, be sure to look through SubstNonTypeTemplateParmExprs. Then, update the IR generation of CallExprs to actually use CallExpr::getCalleeDecl() rather than attempting to mimick its behavior (badly). Fixes <rdar://problem/10063539>. llvm-svn: 139185
2011-09-07 05:41:04 +08:00
const Decl *TargetDecl = E->getCalleeDecl();
if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(TargetDecl)) {
if (unsigned builtinID = FD->getBuiltinID())
Implement the __builtin_call_with_static_chain GNU extension. The extension has the following syntax: __builtin_call_with_static_chain(Call, Chain) where Call must be a function call expression and Chain must be of pointer type This extension performs a function call Call with a static chain pointer Chain passed to the callee in a designated register. This is useful for calling foreign language functions whose ABI uses static chain pointers (e.g. to implement closures). Differential Revision: http://reviews.llvm.org/D6332 llvm-svn: 224167
2014-12-13 07:41:25 +08:00
return EmitBuiltinExpr(FD, builtinID, E, ReturnValue);
Set call attribute for direct calls (i.e. noreturn). - Remove an unused variant of EmitCallExpr overload. llvm-svn: 65130
2009-02-21 02:06:48 +08:00
}
Give "unsupported" error on calls through block pointers instead of crashes. llvm-svn: 61992
2009-01-10 00:50:52 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *CE = dyn_cast<CXXOperatorCallExpr>(E))
Handle operator call expressions where the callee is a member function. llvm-svn: 72458
2009-05-27 12:18:27 +08:00
if (const CXXMethodDecl *MD = dyn_cast_or_null<CXXMethodDecl>(TargetDecl))
Pass the return value slot to all call exprs. llvm-svn: 92145
2009-12-25 05:13:40 +08:00
return EmitCXXOperatorMemberCallExpr(CE, MD, ReturnValue);
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *PseudoDtor =
dyn_cast<CXXPseudoDestructorExpr>(E->getCallee()->IgnoreParens())) {
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
QualType DestroyedType = PseudoDtor->getDestroyedType();
Simplify: replace getContext().getLangOpts() with just getLangOpts(). llvm-svn: 167261
2012-11-02 06:30:59 +08:00
if (getLangOpts().ObjCAutoRefCount &&
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
DestroyedType->isObjCLifetimeType() &&
(DestroyedType.getObjCLifetime() == Qualifiers::OCL_Strong ||
DestroyedType.getObjCLifetime() == Qualifiers::OCL_Weak)) {
80 cols. llvm-svn: 133345
2011-06-18 18:34:00 +08:00
// Automatic Reference Counting:
// If the pseudo-expression names a retainable object with weak or
// strong lifetime, the object shall be released.
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
Expr *BaseExpr = PseudoDtor->getBase();
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address BaseValue = Address::invalid();
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
Qualifiers BaseQuals;
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
80 cols. llvm-svn: 133345
2011-06-18 18:34:00 +08:00
// If this is s.x, emit s as an lvalue. If it is s->x, emit s as a scalar.
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
if (PseudoDtor->isArrow()) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
BaseValue = EmitPointerWithAlignment(BaseExpr);
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
const PointerType *PTy = BaseExpr->getType()->getAs<PointerType>();
BaseQuals = PTy->getPointeeType().getQualifiers();
} else {
LValue BaseLV = EmitLValue(BaseExpr);
BaseValue = BaseLV.getAddress();
QualType BaseTy = BaseExpr->getType();
BaseQuals = BaseTy.getQualifiers();
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
switch (PseudoDtor->getDestroyedType().getObjCLifetime()) {
case Qualifiers::OCL_None:
case Qualifiers::OCL_ExplicitNone:
case Qualifiers::OCL_Autoreleasing:
break;
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
case Qualifiers::OCL_Strong:
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
EmitARCRelease(Builder.CreateLoad(BaseValue,
80 cols. llvm-svn: 133345
2011-06-18 18:34:00 +08:00
PseudoDtor->getDestroyedType().isVolatileQualified()),
Tighten up the rules for precise lifetime and document the requirements on the ARC optimizer. rdar://13407451 llvm-svn: 176924
2013-03-13 11:10:54 +08:00
ARCPreciseLifetime);
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
break;
case Qualifiers::OCL_Weak:
EmitARCDestroyWeak(BaseValue);
break;
}
} else {
// C++ [expr.pseudo]p1:
// The result shall only be used as the operand for the function call
// operator (), and the result of such a call has type void. The only
// effect is the evaluation of the postfix-expression before the dot or
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
// arrow.
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
EmitScalarExpr(E->getCallee());
}
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
return RValue::get(nullptr);
Implement AST, semantics, and CodeGen for C++ pseudo-destructor expressions, e.g., p->~T() when p is a pointer to a scalar type. We don't currently diagnose errors when pseudo-destructor expressions are used in any way other than by forming a call. llvm-svn: 81009
2009-09-05 01:36:40 +08:00
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
completely refactor codegen of scalar expressions out into its own CGExprScalar.cpp file. This patch temporarily breaks compound assignment operators, but greatly simplifies many things. llvm-svn: 41355
2007-08-24 13:35:26 +08:00
llvm::Value *Callee = EmitScalarExpr(E->getCallee());
Pass expressions instead of argument ranges to EmitCall/EmitCXXConstructorCall. Summary: This is a first small step towards passing generic "Expr" instead of ArgBeg/ArgEnd pair into EmitCallArgs() family of methods. Having "Expr" will allow us to get the corresponding FunctionDecl and its ParmVarDecls, thus allowing us to alter CodeGen depending on the function/parameter attributes. No functionality change. Test Plan: regression test suite Reviewers: rnk Reviewed By: rnk Subscribers: aemerson, cfe-commits Differential Revision: http://reviews.llvm.org/D4915 llvm-svn: 216214
2014-08-22 04:26:47 +08:00
return EmitCall(E->getCallee()->getType(), Callee, E, ReturnValue,
TargetDecl);
Implement codegen support for lowering "library builtins" like __builtin_isinf to their corresponding library routines (e.g. isinf). This allows us to handle all the stuff in macos math.h, and other stuff as it's added to *Builtins.def. llvm-svn: 41634
2007-08-31 12:44:06 +08:00
}
Implement codegen of aggregates as lvalues in binary expressions, e.g. "(a = b).somefield". llvm-svn: 55758
2008-09-04 11:20:13 +08:00
LValue CodeGenFunction::EmitBinaryOperatorLValue(const BinaryOperator *E) {
implement l-value codegen of comma expr llvm-svn: 71595
2009-05-13 05:28:12 +08:00
// Comma expressions just emit their LHS then their RHS as an l-value.
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
if (E->getOpcode() == BO_Comma) {
Fix a bug in the emission of __real/__imag l-values on scalar operands. Fix a bug in the emission of complex compound assignment l-values. Introduce a method to emit an expression whose value isn't relevant. Make that method evaluate its operand as an l-value if it is one. Fixes our volatile compliance in C++. llvm-svn: 120931
2010-12-05 10:00:02 +08:00
EmitIgnoredExpr(E->getLHS());
Make the comma operator consistently call EnsureInsertPoint. llvm-svn: 90799
2009-12-08 04:18:11 +08:00
EnsureInsertPoint();
implement l-value codegen of comma expr llvm-svn: 71595
2009-05-13 05:28:12 +08:00
return EmitLValue(E->getRHS());
}
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
GCC didn't care for my attempt at API compatibility, so brute-force everything to the new constants. llvm-svn: 112047
2010-08-25 19:45:40 +08:00
if (E->getOpcode() == BO_PtrMemD ||
E->getOpcode() == BO_PtrMemI)
Complete code gen for '.*' binary expression for both scalar and aggregates. llvm-svn: 84910
2009-10-23 06:57:31 +08:00
return EmitPointerToDataMemberBinaryExpr(E);
Implement codegen of aggregates as lvalues in binary expressions, e.g. "(a = b).somefield". llvm-svn: 55758
2008-09-04 11:20:13 +08:00
Fix a bug in the emission of __real/__imag l-values on scalar operands. Fix a bug in the emission of complex compound assignment l-values. Introduce a method to emit an expression whose value isn't relevant. Make that method evaluate its operand as an l-value if it is one. Fixes our volatile compliance in C++. llvm-svn: 120931
2010-12-05 10:00:02 +08:00
assert(E->getOpcode() == BO_Assign && "unexpected binary l-value");
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
// Note that in all of these cases, __block variables need the RHS
// evaluated first just in case the variable gets moved by the RHS.
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
switch (getEvaluationKind(E->getType())) {
case TEK_Scalar: {
Automatic Reference Counting. Language-design credit goes to a lot of people, but I particularly want to single out Blaine Garst and Patrick Beard for their contributions. Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself, in no particular order. llvm-svn: 133103
2011-06-16 07:02:42 +08:00
switch (E->getLHS()->getType().getObjCLifetime()) {
case Qualifiers::OCL_Strong:
return EmitARCStoreStrong(E, /*ignored*/ false).first;
case Qualifiers::OCL_Autoreleasing:
return EmitARCStoreAutoreleasing(E).first;
// No reason to do any of these differently.
case Qualifiers::OCL_None:
case Qualifiers::OCL_ExplicitNone:
case Qualifiers::OCL_Weak:
break;
}
__block variables require us to evaluate the RHS of an assignment before the LHS, or else the pointer might be invalid. This is kindof dumb, but go ahead and make sure we're doing that for l-value scalar assignment, which fixes a miscompile of obj-c++.dg/block-seq.mm. Leave a FIXME for how to solve this problem for agg __blocks. llvm-svn: 120992
2010-12-06 14:10:02 +08:00
RValue RV = EmitAnyExpr(E->getRHS());
-fcatch-undefined-behavior: emit calls to the runtime library whenever one of the checks fails. llvm-svn: 165536
2012-10-10 03:52:38 +08:00
LValue LV = EmitCheckedLValue(E->getLHS(), TCK_Store);
LValue carries a type now, so simplify the main EmitLoad/Store APIs by removing the redundant type parameter. llvm-svn: 133860
2011-06-25 10:11:03 +08:00
EmitStoreThroughLValue(RV, LV);
Handle emitting the assignment operator when the lhs is a reference. Fixes PR5227. llvm-svn: 84518
2009-10-20 02:28:22 +08:00
return LV;
}
Support compound complex operations as l-values in C++. Add a test case based on CodeGen/volatile-1.c which tests the current C++ semantics, and note the many, many places we fall short of them. llvm-svn: 119402
2010-11-17 07:07:28 +08:00
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
case TEK_Complex:
Support compound complex operations as l-values in C++. Add a test case based on CodeGen/volatile-1.c which tests the current C++ semantics, and note the many, many places we fall short of them. llvm-svn: 119402
2010-11-17 07:07:28 +08:00
return EmitComplexAssignmentLValue(E);
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
case TEK_Aggregate:
return EmitAggExprToLValue(E);
}
llvm_unreachable("bad evaluation kind");
Implement codegen of aggregates as lvalues in binary expressions, e.g. "(a = b).somefield". llvm-svn: 55758
2008-09-04 11:20:13 +08:00
}
Enable CodeGen for member expressions based on call expressions returning aggregate types. This enables expressions like 'foo().member.submember'. llvm-svn: 45395
2007-12-29 13:02:41 +08:00
LValue CodeGenFunction::EmitCallExprLValue(const CallExpr *E) {
RValue RV = EmitCallExpr(E);
Add support for emitting calls to functions that return references (as lvalues only for now) llvm-svn: 72449
2009-05-27 09:45:47 +08:00
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
if (!RV.isScalar())
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(RV.getAggregateAddress(), E->getType(),
AlignmentSource::Decl);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Sema: Parenthesized bound destructor member expressions can be called We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
2015-02-26 01:36:15 +08:00
assert(E->getCallReturnType(getContext())->isReferenceType() &&
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
"Can't have a scalar return unless the return type is a "
"reference type!");
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeNaturalAlignPointeeAddrLValue(RV.getScalarVal(), E->getType());
Enable CodeGen for member expressions based on call expressions returning aggregate types. This enables expressions like 'foo().member.submember'. llvm-svn: 45395
2007-12-29 13:02:41 +08:00
}
Support IRgen of va_arg of structure as l-value. llvm-svn: 64325
2009-02-12 04:59:32 +08:00
LValue CodeGenFunction::EmitVAArgExprLValue(const VAArgExpr *E) {
// FIXME: This shouldn't require another copy.
IRgen: Factor out EmitAggExprToLValue. llvm-svn: 95416
2010-02-06 03:38:31 +08:00
return EmitAggExprToLValue(E);
Support IRgen of va_arg of structure as l-value. llvm-svn: 64325
2009-02-12 04:59:32 +08:00
}
More temporary support. llvm-svn: 72648
2009-05-31 07:23:33 +08:00
LValue CodeGenFunction::EmitCXXConstructLValue(const CXXConstructExpr *E) {
Fix a bug with binding l-values to elided temporaries, and leave a couple helpful asserts behind. llvm-svn: 114250
2010-09-18 08:58:34 +08:00
assert(E->getType()->getAsCXXRecordDecl()->hasTrivialDestructor()
&& "binding l-value to type which needs a temporary");
de-tmpify clang. llvm-svn: 140637
2011-09-28 05:06:10 +08:00
AggValueSlot Slot = CreateAggTemp(E->getType());
one piece of code is responsible for the lifetime of every aggregate slot. The easiest way to do that was to bundle up the information we care about for aggregate slots into a new structure which demands that its creators at least consider the question. I could probably be convinced that the ObjC 'needs GC' bit should be rolled into this structure. Implement generalized copy elision. The main obstacle here is that IR-generation must be much more careful about making sure that exactly llvm-svn: 113962
2010-09-15 18:14:12 +08:00
EmitCXXConstructExpr(E, Slot);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(Slot.getAddress(), E->getType(),
AlignmentSource::Decl);
More temporary support. llvm-svn: 72648
2009-05-31 07:23:33 +08:00
}
Implement typeid for class types. llvm-svn: 88843
2009-11-15 16:09:41 +08:00
LValue
CodeGenFunction::EmitCXXTypeidLValue(const CXXTypeidExpr *E) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeNaturalAlignAddrLValue(EmitCXXTypeidExpr(E), E->getType());
Implement typeid for class types. llvm-svn: 88843
2009-11-15 16:09:41 +08:00
}
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address CodeGenFunction::EmitCXXUuidofExpr(const CXXUuidofExpr *E) {
return Builder.CreateElementBitCast(CGM.GetAddrOfUuidDescriptor(E),
ConvertType(E->getType()));
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
}
LValue CodeGenFunction::EmitCXXUuidofLValue(const CXXUuidofExpr *E) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(EmitCXXUuidofExpr(E), E->getType(),
AlignmentSource::Decl);
Add codegen support for __uuidof(). llvm-svn: 165710
2012-10-11 18:13:44 +08:00
}
Add lvalue irgen support for CXXBindTemporaryExpr. llvm-svn: 72649
2009-05-31 07:30:54 +08:00
LValue
CodeGenFunction::EmitCXXBindTemporaryLValue(const CXXBindTemporaryExpr *E) {
Fix a bug with binding l-values to elided temporaries, and leave a couple helpful asserts behind. llvm-svn: 114250
2010-09-18 08:58:34 +08:00
AggValueSlot Slot = CreateAggTemp(E->getType(), "temp.lvalue");
What say we document some of these AggValueSlot flags a bit better. llvm-svn: 138628
2011-08-26 16:02:37 +08:00
Slot.setExternallyDestructed();
Fix a bug with binding l-values to elided temporaries, and leave a couple helpful asserts behind. llvm-svn: 114250
2010-09-18 08:58:34 +08:00
EmitAggExpr(E->getSubExpr(), Slot);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
EmitCXXTemporary(E->getTemporary(), E->getType(), Slot.getAddress());
return MakeAddrLValue(Slot.getAddress(), E->getType(),
AlignmentSource::Decl);
Add lvalue irgen support for CXXBindTemporaryExpr. llvm-svn: 72649
2009-05-31 07:30:54 +08:00
}
A little bit of lambda IRGen. llvm-svn: 150058
2012-02-08 13:34:55 +08:00
LValue
CodeGenFunction::EmitLambdaLValue(const LambdaExpr *E) {
AggValueSlot Slot = CreateAggTemp(E->getType(), "temp.lvalue");
Refactor lambda IRGen so AggExprEmitter::VisitLambdaExpr does the right thing. llvm-svn: 150146
2012-02-09 11:32:31 +08:00
EmitLambdaExpr(E, Slot);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(Slot.getAddress(), E->getType(),
AlignmentSource::Decl);
A little bit of lambda IRGen. llvm-svn: 150058
2012-02-08 13:34:55 +08:00
}
Implement Obj-C ivar references to aggregates. Implement Obj-C lvalue message sends (aggregate returns). Update several places to emit more precise ErrorUnsupported warnings for currently unimplemented Obj-C features (main missing chunks are property references, Obj-C exception handling, and the for ... in syntax). llvm-svn: 55234
2008-08-23 18:51:21 +08:00
LValue CodeGenFunction::EmitObjCMessageExprLValue(const ObjCMessageExpr *E) {
RValue RV = EmitObjCMessageExpr(E);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Fix an Obj-C++ miscompile when calling an Obj-C method that returns a C++ reference. llvm-svn: 106477
2010-06-22 04:59:55 +08:00
if (!RV.isScalar())
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(RV.getAggregateAddress(), E->getType(),
AlignmentSource::Decl);
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Rename getResultType() on function and method declarations to getReturnType() A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
2014-01-26 00:55:45 +08:00
assert(E->getMethodDecl()->getReturnType()->isReferenceType() &&
Fix an Obj-C++ miscompile when calling an Obj-C method that returns a C++ reference. llvm-svn: 106477
2010-06-22 04:59:55 +08:00
"Can't have a scalar return unless the return type is a "
"reference type!");
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeNaturalAlignPointeeAddrLValue(RV.getScalarVal(), E->getType());
Implement Obj-C ivar references to aggregates. Implement Obj-C lvalue message sends (aggregate returns). Update several places to emit more precise ErrorUnsupported warnings for currently unimplemented Obj-C features (main missing chunks are property references, Obj-C exception handling, and the for ... in syntax). llvm-svn: 55234
2008-08-23 18:51:21 +08:00
}
Objective-c++ IRGen. Support for @selector expression as an lvalue. Fixes PR7390. llvm-svn: 106235
2010-06-18 03:56:20 +08:00
LValue CodeGenFunction::EmitObjCSelectorLValue(const ObjCSelectorExpr *E) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address V =
CGM.getObjCRuntime().GetAddrOfSelector(*this, E->getSelector());
return MakeAddrLValue(V, E->getType(), AlignmentSource::Decl);
Objective-c++ IRGen. Support for @selector expression as an lvalue. Fixes PR7390. llvm-svn: 106235
2010-06-18 03:56:20 +08:00
}
Make ObjCInterfaceDecl's const in some more places. llvm-svn: 69775
2009-04-22 13:08:15 +08:00
llvm::Value *CodeGenFunction::EmitIvarOffset(const ObjCInterfaceDecl *Interface,
Refactor some CodeGen functionality: - Add CodeGenFunction::{EmitReturnOfRValue, EmitIvarOffset} - Factor EmitLValueForIvar out of EmitObjCIvarRefLValue. No non-error functionality change (some unsupported errors are degraded to asserts for the time being). llvm-svn: 56543
2008-09-24 12:00:38 +08:00
const ObjCIvarDecl *Ivar) {
Some refactoring of Ivar offset code gen. in preparation for nonfragile ivar offset work. llvm-svn: 64225
2009-02-11 03:02:04 +08:00
return CGM.getObjCRuntime().EmitIvarOffset(*this, Interface, Ivar);
Refactor some CodeGen functionality: - Add CodeGenFunction::{EmitReturnOfRValue, EmitIvarOffset} - Factor EmitLValueForIvar out of EmitObjCIvarRefLValue. No non-error functionality change (some unsupported errors are degraded to asserts for the time being). llvm-svn: 56543
2008-09-24 12:00:38 +08:00
}
Make code generation of ivar ref exprs more like member exprs. llvm-svn: 55298
2008-08-25 09:53:23 +08:00
objc2's ir-gen for nonfragile ivar access. llvm-svn: 63578
2009-02-03 08:09:52 +08:00
LValue CodeGenFunction::EmitLValueForIvar(QualType ObjectTy,
llvm::Value *BaseValue,
Refactor some CodeGen functionality: - Add CodeGenFunction::{EmitReturnOfRValue, EmitIvarOffset} - Factor EmitLValueForIvar out of EmitObjCIvarRefLValue. No non-error functionality change (some unsupported errors are degraded to asserts for the time being). llvm-svn: 56543
2008-09-24 12:00:38 +08:00
const ObjCIvarDecl *Ivar,
unsigned CVRQualifiers) {
tidy some code. llvm-svn: 69360
2009-04-18 01:44:48 +08:00
return CGM.getObjCRuntime().EmitObjCValueForIvar(*this, ObjectTy, BaseValue,
Kill ASTContext::[gs]etFieldForDecl, instead we just lookup things when we need them -- which is exactly what some code was already doing! - No intended functionality change. llvm-svn: 69648
2009-04-21 09:19:28 +08:00
Ivar, CVRQualifiers);
Refactor some CodeGen functionality: - Add CodeGenFunction::{EmitReturnOfRValue, EmitIvarOffset} - Factor EmitLValueForIvar out of EmitObjCIvarRefLValue. No non-error functionality change (some unsupported errors are degraded to asserts for the time being). llvm-svn: 56543
2008-09-24 12:00:38 +08:00
}
LValue CodeGenFunction::EmitObjCIvarRefLValue(const ObjCIvarRefExpr *E) {
Make code generation of ivar ref exprs more like member exprs. llvm-svn: 55298
2008-08-25 09:53:23 +08:00
// FIXME: A lot of the code below could be shared with EmitMemberExpr.
[C++11] Use 'nullptr'. CodeGen edition. llvm-svn: 209272
2014-05-21 13:09:00 +08:00
llvm::Value *BaseValue = nullptr;
Make code generation of ivar ref exprs more like member exprs. llvm-svn: 55298
2008-08-25 09:53:23 +08:00
const Expr *BaseExpr = E->getBase();
Refactor the representation of qualifiers to bring ExtQualType out of the Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our use of qualifiers and fix a few places that weren't dealing with qualifiers quite right; many more remain. llvm-svn: 82705
2009-09-25 03:53:00 +08:00
Qualifiers BaseQuals;
objc2's ir-gen for nonfragile ivar access. llvm-svn: 63578
2009-02-03 08:09:52 +08:00
QualType ObjectTy;
Make code generation of ivar ref exprs more like member exprs. llvm-svn: 55298
2008-08-25 09:53:23 +08:00
if (E->isArrow()) {
BaseValue = EmitScalarExpr(BaseExpr);
This patch includes a conceptually simple, but very intrusive/pervasive change. The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObjectPointerType). The fun starts in Sema::GetTypeForDeclarator(), where "SomeInterface *" is now represented by a single AST node (rather than a PointerType whose Pointee is an ObjCInterfaceType). Since a significant amount of code assumed ObjC object pointers where based on C pointers/structs, this patch is very tedious. It should also explain why it is hard to accomplish this in smaller, self-contained patches. This patch does most of the "heavy lifting" related to moving from PointerType->ObjCObjectPointerType. It doesn't include all potential "cleanups". The good news is additional cleanups can be done later (some are noted in the code). This patch is so large that I didn't want to include any changes that are purely aesthetic. By making the ObjC types truly built-in, they are much easier to work with (and require fewer "hacks"). For example, there is no need for ASTContext::isObjCIdStructType() or ASTContext::isObjCClassStructType()! We believe this change (and the follow-up cleanups) will pay dividends over time. Given the amount of code change, I do expect some fallout from this change (though it does pass all of the clang tests). If you notice any problems, please let us know asap! Thanks. llvm-svn: 75314
2009-07-11 07:34:53 +08:00
ObjectTy = BaseExpr->getType()->getPointeeType();
Refactor the representation of qualifiers to bring ExtQualType out of the Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our use of qualifiers and fix a few places that weren't dealing with qualifiers quite right; many more remain. llvm-svn: 82705
2009-09-25 03:53:00 +08:00
BaseQuals = ObjectTy.getQualifiers();
Make code generation of ivar ref exprs more like member exprs. llvm-svn: 55298
2008-08-25 09:53:23 +08:00
} else {
LValue BaseLV = EmitLValue(BaseExpr);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
BaseValue = BaseLV.getPointer();
objc2's ir-gen for nonfragile ivar access. llvm-svn: 63578
2009-02-03 08:09:52 +08:00
ObjectTy = BaseExpr->getType();
Refactor the representation of qualifiers to bring ExtQualType out of the Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our use of qualifiers and fix a few places that weren't dealing with qualifiers quite right; many more remain. llvm-svn: 82705
2009-09-25 03:53:00 +08:00
BaseQuals = ObjectTy.getQualifiers();
Make code generation of ivar ref exprs more like member exprs. llvm-svn: 55298
2008-08-25 09:53:23 +08:00
}
Refactor some CodeGen functionality: - Add CodeGenFunction::{EmitReturnOfRValue, EmitIvarOffset} - Factor EmitLValueForIvar out of EmitObjCIvarRefLValue. No non-error functionality change (some unsupported errors are degraded to asserts for the time being). llvm-svn: 56543
2008-09-24 12:00:38 +08:00
Remove trailing whitespace. llvm-svn: 187189
2013-07-26 13:59:26 +08:00
LValue LV =
Refactor the representation of qualifiers to bring ExtQualType out of the Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our use of qualifiers and fix a few places that weren't dealing with qualifiers quite right; many more remain. llvm-svn: 82705
2009-09-25 03:53:00 +08:00
EmitLValueForIvar(ObjectTy, BaseValue, E->getDecl(),
BaseQuals.getCVRQualifiers());
patch for generating objc'2 objc_assign_ivar. WIP. llvm-svn: 82090
2009-09-17 07:11:23 +08:00
setObjCGCLValueClass(getContext(), E, LV);
return LV;
Add initial support for objc codegen for methods, ivars, and the etoile runtime, patch by David Chisnall! llvm-svn: 48969
2008-03-31 07:03:07 +08:00
}
fix PR4067: [Linux kernel] cannot aggregate codegen stmtexpr as lvalue llvm-svn: 70067
2009-04-26 03:35:26 +08:00
LValue CodeGenFunction::EmitStmtExprLValue(const StmtExpr *E) {
// Can only get l-value for message expression returning aggregate type
RValue RV = EmitAnyExprToTemp(E);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(RV.getAggregateAddress(), E->getType(),
AlignmentSource::Decl);
fix PR4067: [Linux kernel] cannot aggregate codegen stmtexpr as lvalue llvm-svn: 70067
2009-04-26 03:35:26 +08:00
}
Add a ReturnValueSlot class. Change the argument order in EmitCall to match the other overload better. llvm-svn: 92136
2009-12-25 03:08:58 +08:00
RValue CodeGenFunction::EmitCall(QualType CalleeType, llvm::Value *Callee,
Pass expressions instead of argument ranges to EmitCall/EmitCXXConstructorCall. Summary: This is a first small step towards passing generic "Expr" instead of ArgBeg/ArgEnd pair into EmitCallArgs() family of methods. Having "Expr" will allow us to get the corresponding FunctionDecl and its ParmVarDecls, thus allowing us to alter CodeGen depending on the function/parameter attributes. No functionality change. Test Plan: regression test suite Reviewers: rnk Reviewed By: rnk Subscribers: aemerson, cfe-commits Differential Revision: http://reviews.llvm.org/D4915 llvm-svn: 216214
2014-08-22 04:26:47 +08:00
const CallExpr *E, ReturnValueSlot ReturnValue,
Implement the __builtin_call_with_static_chain GNU extension. The extension has the following syntax: __builtin_call_with_static_chain(Call, Chain) where Call must be a function call expression and Chain must be of pointer type This extension performs a function call Call with a static chain pointer Chain passed to the callee in a designated register. This is useful for calling foreign language functions whose ABI uses static chain pointers (e.g. to implement closures). Differential Revision: http://reviews.llvm.org/D6332 llvm-svn: 224167
2014-12-13 07:41:25 +08:00
const Decl *TargetDecl, llvm::Value *Chain) {
Reflow comments and some minor whitespace fixups. llvm-svn: 81337
2009-09-09 21:00:44 +08:00
// Get the actual function type. The callee type will always be a pointer to
// function type or a block pointer type.
assert(CalleeType->isFunctionPointerType() &&
Remove some dead code. llvm-svn: 68532
2009-04-08 02:53:02 +08:00
"Call must have function pointer type!");
Emit calls using the canonical prototype of the called function. llvm-svn: 84947
2009-10-23 16:22:42 +08:00
CalleeType = getContext().getCanonicalType(CalleeType);
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
const auto *FnType =
cast<FunctionType>(cast<PointerType>(CalleeType)->getPointeeType());
Refactor handling of calls: - Added CodeGenFunction::EmitCall which just takes the callee, return type, and a list of (Value*,QualType) pairs. - Added CodeGenFunction::EmitCallArg which handles emitting code for a call argument and turning it into an appropriate (Value*,QualType) pair. - Changed Objective-C runtime interface so that the actual emission of arguments for message sends is (once again) done in the code to emit a message send. No intended functionality change, this is prep work for better ABI support and for Objective-C property setter support. llvm-svn: 55560
2008-08-30 11:02:31 +08:00
Introduce a SanitizerKind enum to LangOptions. Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
2014-11-08 06:29:38 +08:00
if (getLangOpts().CPlusPlus && SanOpts.has(SanitizerKind::Function) &&
Implement function type checker for the undefined behavior sanitizer. This uses function prefix data to store function type information at the function pointer. Differential Revision: http://llvm-reviews.chandlerc.com/D1338 llvm-svn: 193058
2013-10-21 05:29:19 +08:00
(!TargetDecl || !isa<FunctionDecl>(TargetDecl))) {
if (llvm::Constant *PrefixSig =
CGM.getTargetCodeGenInfo().getUBSanFunctionSignature(CGM)) {
[UBSan] Add !nosanitize metadata to the code generated by UBSan. This is used to mark the instructions emitted by Clang to implement variety of UBSan checks. Generally, we don't want to instrument these instructions with another sanitizers (like ASan). Reviewed in http://reviews.llvm.org/D4544 llvm-svn: 213291
2014-07-18 02:46:27 +08:00
SanitizerScope SanScope(this);
Implement function type checker for the undefined behavior sanitizer. This uses function prefix data to store function type information at the function pointer. Differential Revision: http://llvm-reviews.chandlerc.com/D1338 llvm-svn: 193058
2013-10-21 05:29:19 +08:00
llvm::Constant *FTRTTIConst =
CGM.GetAddrOfRTTIDescriptor(QualType(FnType, 0), /*ForEH=*/true);
llvm::Type *PrefixStructTyElems[] = {
PrefixSig->getType(),
FTRTTIConst->getType()
};
llvm::StructType *PrefixStructTy = llvm::StructType::get(
CGM.getLLVMContext(), PrefixStructTyElems, /*isPacked=*/true);
llvm::Value *CalleePrefixStruct = Builder.CreateBitCast(
Callee, llvm::PointerType::getUnqual(PrefixStructTy));
llvm::Value *CalleeSigPtr =
[opaque pointer type] More GEP API migrations llvm-svn: 234109
2015-04-05 05:07:17 +08:00
Builder.CreateConstGEP2_32(PrefixStructTy, CalleePrefixStruct, 0, 0);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *CalleeSig =
Builder.CreateAlignedLoad(CalleeSigPtr, getIntAlign());
Implement function type checker for the undefined behavior sanitizer. This uses function prefix data to store function type information at the function pointer. Differential Revision: http://llvm-reviews.chandlerc.com/D1338 llvm-svn: 193058
2013-10-21 05:29:19 +08:00
llvm::Value *CalleeSigMatch = Builder.CreateICmpEQ(CalleeSig, PrefixSig);
llvm::BasicBlock *Cont = createBasicBlock("cont");
llvm::BasicBlock *TypeCheck = createBasicBlock("typecheck");
Builder.CreateCondBr(CalleeSigMatch, TypeCheck, Cont);
EmitBlock(TypeCheck);
llvm::Value *CalleeRTTIPtr =
[opaque pointer type] More GEP API migrations llvm-svn: 234109
2015-04-05 05:07:17 +08:00
Builder.CreateConstGEP2_32(PrefixStructTy, CalleePrefixStruct, 0, 1);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
llvm::Value *CalleeRTTI =
Builder.CreateAlignedLoad(CalleeRTTIPtr, getPointerAlign());
Implement function type checker for the undefined behavior sanitizer. This uses function prefix data to store function type information at the function pointer. Differential Revision: http://llvm-reviews.chandlerc.com/D1338 llvm-svn: 193058
2013-10-21 05:29:19 +08:00
llvm::Value *CalleeRTTIMatch =
Builder.CreateICmpEQ(CalleeRTTI, FTRTTIConst);
llvm::Constant *StaticData[] = {
Pass expressions instead of argument ranges to EmitCall/EmitCXXConstructorCall. Summary: This is a first small step towards passing generic "Expr" instead of ArgBeg/ArgEnd pair into EmitCallArgs() family of methods. Having "Expr" will allow us to get the corresponding FunctionDecl and its ParmVarDecls, thus allowing us to alter CodeGen depending on the function/parameter attributes. No functionality change. Test Plan: regression test suite Reviewers: rnk Reviewed By: rnk Subscribers: aemerson, cfe-commits Differential Revision: http://reviews.llvm.org/D4915 llvm-svn: 216214
2014-08-22 04:26:47 +08:00
EmitCheckSourceLocation(E->getLocStart()),
Implement function type checker for the undefined behavior sanitizer. This uses function prefix data to store function type information at the function pointer. Differential Revision: http://llvm-reviews.chandlerc.com/D1338 llvm-svn: 193058
2013-10-21 05:29:19 +08:00
EmitCheckTypeDescriptor(CalleeType)
};
Bundle conditions checked by UBSan with sanitizer kinds they implement. Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
2014-11-12 06:03:54 +08:00
EmitCheck(std::make_pair(CalleeRTTIMatch, SanitizerKind::Function),
"function_type_mismatch", StaticData, Callee);
Implement function type checker for the undefined behavior sanitizer. This uses function prefix data to store function type information at the function pointer. Differential Revision: http://llvm-reviews.chandlerc.com/D1338 llvm-svn: 193058
2013-10-21 05:29:19 +08:00
Builder.CreateBr(Cont);
EmitBlock(Cont);
}
}
CFI: Introduce -fsanitize=cfi-icall flag. This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism. Differential Revision: http://reviews.llvm.org/D11857 llvm-svn: 247238
2015-09-10 10:17:40 +08:00
// If we are checking indirect calls and this call is indirect, check that the
// function pointer is a member of the bit set for the function type.
if (SanOpts.has(SanitizerKind::CFIICall) &&
(!TargetDecl || !isa<FunctionDecl>(TargetDecl))) {
SanitizerScope SanScope(this);
llvm::Value *BitSetName = llvm::MetadataAsValue::get(
getLLVMContext(),
CGM.CreateMetadataIdentifierForType(QualType(FnType, 0)));
llvm::Value *CastedCallee = Builder.CreateBitCast(Callee, Int8PtrTy);
llvm::Value *BitSetTest =
Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::bitset_test),
{CastedCallee, BitSetName});
llvm::Constant *StaticData[] = {
EmitCheckSourceLocation(E->getLocStart()),
EmitCheckTypeDescriptor(QualType(FnType, 0)),
};
EmitCheck(std::make_pair(BitSetTest, SanitizerKind::CFIICall),
"cfi_bad_icall", StaticData, CastedCallee);
}
Refactor handling of calls: - Added CodeGenFunction::EmitCall which just takes the callee, return type, and a list of (Value*,QualType) pairs. - Added CodeGenFunction::EmitCallArg which handles emitting code for a call argument and turning it into an appropriate (Value*,QualType) pair. - Changed Objective-C runtime interface so that the actual emission of arguments for message sends is (once again) done in the code to emit a message send. No intended functionality change, this is prep work for better ABI support and for Objective-C property setter support. llvm-svn: 55560
2008-08-30 11:02:31 +08:00
CallArgList Args;
Implement the __builtin_call_with_static_chain GNU extension. The extension has the following syntax: __builtin_call_with_static_chain(Call, Chain) where Call must be a function call expression and Chain must be of pointer type This extension performs a function call Call with a static chain pointer Chain passed to the callee in a designated register. This is useful for calling foreign language functions whose ABI uses static chain pointers (e.g. to implement closures). Differential Revision: http://reviews.llvm.org/D6332 llvm-svn: 224167
2014-12-13 07:41:25 +08:00
if (Chain)
Args.add(RValue::get(Builder.CreateBitCast(Chain, CGM.VoidPtrTy)),
CGM.getContext().VoidPtrTy);
Pass an iterator range to EmitCallArgs llvm-svn: 242824
2015-07-22 02:37:18 +08:00
EmitCallArgs(Args, dyn_cast<FunctionProtoType>(FnType), E->arguments(),
E->getDirectCallee(), /*ParamsToSkip*/ 0);
Refactor handling of calls: - Added CodeGenFunction::EmitCall which just takes the callee, return type, and a list of (Value*,QualType) pairs. - Added CodeGenFunction::EmitCallArg which handles emitting code for a call argument and turning it into an appropriate (Value*,QualType) pair. - Changed Objective-C runtime interface so that the actual emission of arguments for message sends is (once again) done in the code to emit a message send. No intended functionality change, this is prep work for better ABI support and for Objective-C property setter support. llvm-svn: 55560
2008-08-30 11:02:31 +08:00
Implement the __builtin_call_with_static_chain GNU extension. The extension has the following syntax: __builtin_call_with_static_chain(Call, Chain) where Call must be a function call expression and Chain must be of pointer type This extension performs a function call Call with a static chain pointer Chain passed to the callee in a designated register. This is useful for calling foreign language functions whose ABI uses static chain pointers (e.g. to implement closures). Differential Revision: http://reviews.llvm.org/D6332 llvm-svn: 224167
2014-12-13 07:41:25 +08:00
const CGFunctionInfo &FnInfo = CGM.getTypes().arrangeFreeFunctionCall(
Args, FnType, /*isChainCall=*/Chain);
ANSI C requires that a call to an unprototyped function type succeed if the definition has a non-variadic prototype with compatible parameters. Therefore, the default rule for such calls must be to use a non-variadic convention. Achieve this by casting the callee to the function type with which it is required to be compatible, unless the target specifically opts out and insists that unprototyped calls should use the variadic rules. The only case of that I'm aware of is the x86-64 convention, which passes arguments the same way in both cases but also sets a small amount of extra information; here we seek to maintain compatibility with GCC, which does set this when calling an unprototyped function. Addresses PR10810 and PR10713. llvm-svn: 140241
2011-09-21 16:08:30 +08:00
// C99 6.5.2.2p6:
// If the expression that denotes the called function has a type
// that does not include a prototype, [the default argument
// promotions are performed]. If the number of arguments does not
// equal the number of parameters, the behavior is undefined. If
// the function is defined with a type that includes a prototype,
// and either the prototype ends with an ellipsis (, ...) or the
// types of the arguments after promotion are not compatible with
// the types of the parameters, the behavior is undefined. If the
// function is defined with a type that does not include a
// prototype, and the types of the arguments after promotion are
// not compatible with those of the parameters after promotion,
// the behavior is undefined [except in some trivial cases].
// That is, in the general case, we should assume that a call
// through an unprototyped function type works like a *non-variadic*
// call. The way we make this work is to cast to the exact type
// of the promoted arguments.
Implement the __builtin_call_with_static_chain GNU extension. The extension has the following syntax: __builtin_call_with_static_chain(Call, Chain) where Call must be a function call expression and Chain must be of pointer type This extension performs a function call Call with a static chain pointer Chain passed to the callee in a designated register. This is useful for calling foreign language functions whose ABI uses static chain pointers (e.g. to implement closures). Differential Revision: http://reviews.llvm.org/D6332 llvm-svn: 224167
2014-12-13 07:41:25 +08:00
//
// Chain calls use this same code path to add the invisible chain parameter
// to the function type.
if (isa<FunctionNoProtoType>(FnType) || Chain) {
Whether an argument is required (in contrast with being an optional argument passed through the variadic ellipsis) potentially affects how we need to lower it. Propagate this information down to the various getFunctionInfo(...) overloads on CodeGenTypes. Furthermore, rename those overloads to clarify their distinct purposes, and make sure we're calling the right one in the right place. This has a nice side-effect of making it easier to construct a function type, since the 'variadic' bit is no longer separable. This shouldn't really change anything for our existing platforms, with one minor exception --- we should now call variadic ObjC methods with the ... in the "right place" (see the test case), which I guess matters for anyone running GNUStep on MIPS. Mostly it's just a substantial clean-up. llvm-svn: 150788
2012-02-17 11:33:10 +08:00
llvm::Type *CalleeTy = getTypes().GetFunctionType(FnInfo);
ANSI C requires that a call to an unprototyped function type succeed if the definition has a non-variadic prototype with compatible parameters. Therefore, the default rule for such calls must be to use a non-variadic convention. Achieve this by casting the callee to the function type with which it is required to be compatible, unless the target specifically opts out and insists that unprototyped calls should use the variadic rules. The only case of that I'm aware of is the x86-64 convention, which passes arguments the same way in both cases but also sets a small amount of extra information; here we seek to maintain compatibility with GCC, which does set this when calling an unprototyped function. Addresses PR10810 and PR10713. llvm-svn: 140241
2011-09-21 16:08:30 +08:00
CalleeTy = CalleeTy->getPointerTo();
Callee = Builder.CreateBitCast(Callee, CalleeTy, "callee.knr.cast");
}
return EmitCall(FnInfo, Callee, ReturnValue, Args, TargetDecl);
Trim CGObjCRuntime::GenerateMessageSend[Super] - Returns an RValue. - Reduced to only taking the CodeGenFunction, Expr, and Receiver. - Becomes responsible for emitting the arguments. Add CodeGenFunction::EmitCallExprExt - Takes optional extra arguments to insert at the head of the call. - This allows the Obj-C runtimes to call into this and isolates the argument and call instruction generation code to one place. Upshot is that we now pass structures (more) correctly. Also, fix one aspect of generating methods which take structure arguments (for NeXT). This probably needs to be merged with the SetFunctionAttributes code in CodeGenModule.cpp llvm-svn: 55223
2008-08-23 11:46:30 +08:00
}
Complete code gen for '.*' binary expression for both scalar and aggregates. llvm-svn: 84910
2009-10-23 06:57:31 +08:00
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
LValue CodeGenFunction::
EmitPointerToDataMemberBinaryExpr(const BinaryOperator *E) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
Address BaseAddr = Address::invalid();
if (E->getOpcode() == BO_PtrMemI) {
BaseAddr = EmitPointerWithAlignment(E->getLHS());
} else {
BaseAddr = EmitLValue(E->getLHS()).getAddress();
}
Amusingly, I missed this point of abstraction in all my earlier member-pointer refactoring: dereferencing a member data pointer. llvm-svn: 112640
2010-09-01 05:07:20 +08:00
Clean up EmitPointerToDataMemberBinaryExpr a bit. llvm-svn: 89197
2009-11-18 13:01:17 +08:00
llvm::Value *OffsetV = EmitScalarExpr(E->getRHS());
random tidying llvm-svn: 85408
2009-10-29 01:39:19 +08:00
Amusingly, I missed this point of abstraction in all my earlier member-pointer refactoring: dereferencing a member data pointer. llvm-svn: 112640
2010-09-01 05:07:20 +08:00
const MemberPointerType *MPT
= E->getRHS()->getType()->getAs<MemberPointerType>();
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
AlignmentSource AlignSource;
Address MemberAddr =
EmitCXXMemberDataPointerAddress(E, BaseAddr, OffsetV, MPT,
&AlignSource);
Amusingly, I missed this point of abstraction in all my earlier member-pointer refactoring: dereferencing a member data pointer. llvm-svn: 112640
2010-09-01 05:07:20 +08:00
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
return MakeAddrLValue(MemberAddr, MPT->getPointeeType(), AlignSource);
Complete code gen for '.*' binary expression for both scalar and aggregates. llvm-svn: 84910
2009-10-23 06:57:31 +08:00
}
Initial implementation of __atomic_* (everything except __atomic_is_lock_free). llvm-svn: 141632
2011-10-11 10:20:01 +08:00
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
/// Given the address of a temporary variable, produce an r-value of
/// its type.
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
RValue CodeGenFunction::convertTempToRValue(Address addr,
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
QualType type,
SourceLocation loc) {
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue lvalue = MakeAddrLValue(addr, type, AlignmentSource::Decl);
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
switch (getEvaluationKind(type)) {
case TEK_Complex:
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
return RValue::getComplex(EmitLoadOfComplex(lvalue, loc));
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
case TEK_Aggregate:
return lvalue.asAggregateRValue();
case TEK_Scalar:
Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs when scalars are loaded / undergo lvalue-to-rvalue conversion. llvm-svn: 191808
2013-10-02 10:29:49 +08:00
return RValue::get(EmitLoadOfScalar(lvalue, loc));
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
}
llvm_unreachable("bad evaluation kind");
Initial implementation of __atomic_* (everything except __atomic_is_lock_free). llvm-svn: 141632
2011-10-11 10:20:01 +08:00
}
Express the number of ULPs in fpaccuracy metadata as a real rather than a rational number, eg as 2.5 rather than 5, 2. OK'd by Peter Collingbourne. llvm-svn: 154388
2012-04-10 16:23:07 +08:00
void CodeGenFunction::SetFPAccuracy(llvm::Value *Val, float Accuracy) {
Annotate imprecise FP division with fpaccuracy metadata The OpenCL single precision division operation is only required to be accurate to 2.5ulp. Annotate the fdiv instruction with metadata which signals to the backend that an imprecise divide instruction may be used. llvm-svn: 143136
2011-10-28 03:19:51 +08:00
assert(Val->getType()->isFPOrFPVectorTy());
Express the number of ULPs in fpaccuracy metadata as a real rather than a rational number, eg as 2.5 rather than 5, 2. OK'd by Peter Collingbourne. llvm-svn: 154388
2012-04-10 16:23:07 +08:00
if (Accuracy == 0.0 || !isa<llvm::Instruction>(Val))
Annotate imprecise FP division with fpaccuracy metadata The OpenCL single precision division operation is only required to be accurate to 2.5ulp. Annotate the fdiv instruction with metadata which signals to the backend that an imprecise divide instruction may be used. llvm-svn: 143136
2011-10-28 03:19:51 +08:00
return;
Adjust for LLVM name tweaks requested by Chandler. llvm-svn: 154824
2012-04-17 00:29:47 +08:00
llvm::MDBuilder MDHelper(getLLVMContext());
llvm::MDNode *Node = MDHelper.createFPMath(Accuracy);
Annotate imprecise FP division with fpaccuracy metadata The OpenCL single precision division operation is only required to be accurate to 2.5ulp. Annotate the fdiv instruction with metadata which signals to the backend that an imprecise divide instruction may be used. llvm-svn: 143136
2011-10-28 03:19:51 +08:00
Rename "fpaccuracy" metadata to the more generic "fpmath". That's because I'm thinking of generalizing it to be able to specify other freedoms beyond accuracy (such as that NaN's don't have to be respected). I'd like the 3.1 release (the first one with this metadata) to have the more generic name already rather than having to auto-upgrade it in 3.2. llvm-svn: 154745
2012-04-14 20:37:26 +08:00
cast<llvm::Instruction>(Val)->setMetadata(llvm::LLVMContext::MD_fpmath, Node);
Annotate imprecise FP division with fpaccuracy metadata The OpenCL single precision division operation is only required to be accurate to 2.5ulp. Annotate the fdiv instruction with metadata which signals to the backend that an imprecise divide instruction may be used. llvm-svn: 143136
2011-10-28 03:19:51 +08:00
}
Change the AST representation of operations on Objective-C property references to use a new PseudoObjectExpr expression which pairs a syntactic form of the expression with a set of semantic expressions implementing it. This should significantly reduce the complexity required elsewhere in the compiler to deal with these kinds of expressions (e.g. IR generation's special l-value kind, the static analyzer's Message abstraction), at the lower cost of specifically dealing with the odd AST structure of these expressions. It should also greatly simplify efforts to implement similar language features in the future, most notably Managed C++'s properties and indexed properties. Most of the effort here is in dealing with the various clients of the AST. I've gone ahead and simplified the ObjC rewriter's use of properties; other clients, like IR-gen and the static analyzer, have all the old complexity *and* all the new complexity, at least temporarily. Many thanks to Ted for writing and advising on the necessary changes to the static analyzer. I've xfailed a small diagnostics regression in the static analyzer at Ted's request. llvm-svn: 143867
2011-11-06 17:01:30 +08:00
namespace {
struct LValueOrRValue {
LValue LV;
RValue RV;
};
}
static LValueOrRValue emitPseudoObjectExpr(CodeGenFunction &CGF,
const PseudoObjectExpr *E,
bool forLValue,
AggValueSlot slot) {
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVector<CodeGenFunction::OpaqueValueMappingData, 4> opaques;
Change the AST representation of operations on Objective-C property references to use a new PseudoObjectExpr expression which pairs a syntactic form of the expression with a set of semantic expressions implementing it. This should significantly reduce the complexity required elsewhere in the compiler to deal with these kinds of expressions (e.g. IR generation's special l-value kind, the static analyzer's Message abstraction), at the lower cost of specifically dealing with the odd AST structure of these expressions. It should also greatly simplify efforts to implement similar language features in the future, most notably Managed C++'s properties and indexed properties. Most of the effort here is in dealing with the various clients of the AST. I've gone ahead and simplified the ObjC rewriter's use of properties; other clients, like IR-gen and the static analyzer, have all the old complexity *and* all the new complexity, at least temporarily. Many thanks to Ted for writing and advising on the necessary changes to the static analyzer. I've xfailed a small diagnostics regression in the static analyzer at Ted's request. llvm-svn: 143867
2011-11-06 17:01:30 +08:00
// Find the result expression, if any.
const Expr *resultExpr = E->getResultExpr();
LValueOrRValue result;
for (PseudoObjectExpr::const_semantics_iterator
i = E->semantics_begin(), e = E->semantics_end(); i != e; ++i) {
const Expr *semantic = *i;
// If this semantic expression is an opaque value, bind it
// to the result of its source expression.
Use auto to avoid duplicating the type. llvm-svn: 208374
2014-05-09 08:08:36 +08:00
if (const auto *ov = dyn_cast<OpaqueValueExpr>(semantic)) {
Change the AST representation of operations on Objective-C property references to use a new PseudoObjectExpr expression which pairs a syntactic form of the expression with a set of semantic expressions implementing it. This should significantly reduce the complexity required elsewhere in the compiler to deal with these kinds of expressions (e.g. IR generation's special l-value kind, the static analyzer's Message abstraction), at the lower cost of specifically dealing with the odd AST structure of these expressions. It should also greatly simplify efforts to implement similar language features in the future, most notably Managed C++'s properties and indexed properties. Most of the effort here is in dealing with the various clients of the AST. I've gone ahead and simplified the ObjC rewriter's use of properties; other clients, like IR-gen and the static analyzer, have all the old complexity *and* all the new complexity, at least temporarily. Many thanks to Ted for writing and advising on the necessary changes to the static analyzer. I've xfailed a small diagnostics regression in the static analyzer at Ted's request. llvm-svn: 143867
2011-11-06 17:01:30 +08:00
// If this is the result expression, we may need to evaluate
// directly into the slot.
typedef CodeGenFunction::OpaqueValueMappingData OVMA;
OVMA opaqueData;
if (ov == resultExpr && ov->isRValue() && !forLValue &&
Change hasAggregateLLVMType, which conflates complex and aggregate types in a profoundly wrong way that has to be worked around in every call site, to getEvaluationKind, which classifies and distinguishes between all of these cases. Also, normalize the API for loading and storing complexes. I'm working on a larger patch and wanted to pull these changes out, but it would have be annoying to detangle them from each other. llvm-svn: 176656
2013-03-08 05:37:08 +08:00
CodeGenFunction::hasAggregateEvaluationKind(ov->getType())) {
Change the AST representation of operations on Objective-C property references to use a new PseudoObjectExpr expression which pairs a syntactic form of the expression with a set of semantic expressions implementing it. This should significantly reduce the complexity required elsewhere in the compiler to deal with these kinds of expressions (e.g. IR generation's special l-value kind, the static analyzer's Message abstraction), at the lower cost of specifically dealing with the odd AST structure of these expressions. It should also greatly simplify efforts to implement similar language features in the future, most notably Managed C++'s properties and indexed properties. Most of the effort here is in dealing with the various clients of the AST. I've gone ahead and simplified the ObjC rewriter's use of properties; other clients, like IR-gen and the static analyzer, have all the old complexity *and* all the new complexity, at least temporarily. Many thanks to Ted for writing and advising on the necessary changes to the static analyzer. I've xfailed a small diagnostics regression in the static analyzer at Ted's request. llvm-svn: 143867
2011-11-06 17:01:30 +08:00
CGF.EmitAggExpr(ov->getSourceExpr(), slot);
Compute and preserve alignment more faithfully in IR-generation. Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
2015-09-08 16:05:57 +08:00
LValue LV = CGF.MakeAddrLValue(slot.getAddress(), ov->getType(),
AlignmentSource::Decl);
Change the AST representation of operations on Objective-C property references to use a new PseudoObjectExpr expression which pairs a syntactic form of the expression with a set of semantic expressions implementing it. This should significantly reduce the complexity required elsewhere in the compiler to deal with these kinds of expressions (e.g. IR generation's special l-value kind, the static analyzer's Message abstraction), at the lower cost of specifically dealing with the odd AST structure of these expressions. It should also greatly simplify efforts to implement similar language features in the future, most notably Managed C++'s properties and indexed properties. Most of the effort here is in dealing with the various clients of the AST. I've gone ahead and simplified the ObjC rewriter's use of properties; other clients, like IR-gen and the static analyzer, have all the old complexity *and* all the new complexity, at least temporarily. Many thanks to Ted for writing and advising on the necessary changes to the static analyzer. I've xfailed a small diagnostics regression in the static analyzer at Ted's request. llvm-svn: 143867
2011-11-06 17:01:30 +08:00
opaqueData = OVMA::bind(CGF, ov, LV);
result.RV = slot.asRValue();
// Otherwise, emit as normal.
} else {
opaqueData = OVMA::bind(CGF, ov, ov->getSourceExpr());
// If this is the result, also evaluate the result now.
if (ov == resultExpr) {
if (forLValue)
result.LV = CGF.EmitLValue(ov);
else
result.RV = CGF.EmitAnyExpr(ov, slot);
}
}
opaques.push_back(opaqueData);
// Otherwise, if the expression is the result, evaluate it
// and remember the result.
} else if (semantic == resultExpr) {
if (forLValue)
result.LV = CGF.EmitLValue(semantic);
else
result.RV = CGF.EmitAnyExpr(semantic, slot);
// Otherwise, evaluate the expression in an ignored context.
} else {
CGF.EmitIgnoredExpr(semantic);
}
}
// Unbind all the opaques now.
for (unsigned i = 0, e = opaques.size(); i != e; ++i)
opaques[i].unbind(CGF);
return result;
}
RValue CodeGenFunction::EmitPseudoObjectRValue(const PseudoObjectExpr *E,
AggValueSlot slot) {
return emitPseudoObjectExpr(*this, E, false, slot).RV;
}
LValue CodeGenFunction::EmitPseudoObjectLValue(const PseudoObjectExpr *E) {
return emitPseudoObjectExpr(*this, E, true, AggValueSlot::ignored()).LV;
}