forked from OSchip/llvm-project
47d28e07c1
Without setting the CurEHLocation these cleanups would be attributed to whatever the last active debug line location was (the 'fn' call in the included test cases). By setting CurEHLocation correctly the line information is improved/corrected. This quality bug turned into a crasher with r225000 when, instead of allowing the last location to persist, it would be zero'd out. This could lead to a function call (such as the dtor) being made without a debug location - if that call was subsequently inlined (and the caller and callee had debug info, just not the call instruction) the inliner would violate important constraints about the debug location chains by not updating the inlined instructions to chain up to the callee locations. So, by fixing this bug, I am addressing the assertion failures introduced by r225000 and should be able to recommit that patch with impunity... llvm-svn: 225955 |
||
---|---|---|
.. | ||
ABIInfo.h | ||
BackendUtil.cpp | ||
CGAtomic.cpp | ||
CGBlocks.cpp | ||
CGBlocks.h | ||
CGBuilder.h | ||
CGBuiltin.cpp | ||
CGCUDANV.cpp | ||
CGCUDARuntime.cpp | ||
CGCUDARuntime.h | ||
CGCXX.cpp | ||
CGCXXABI.cpp | ||
CGCXXABI.h | ||
CGCall.cpp | ||
CGCall.h | ||
CGClass.cpp | ||
CGCleanup.cpp | ||
CGCleanup.h | ||
CGDebugInfo.cpp | ||
CGDebugInfo.h | ||
CGDecl.cpp | ||
CGDeclCXX.cpp | ||
CGException.cpp | ||
CGExpr.cpp | ||
CGExprAgg.cpp | ||
CGExprCXX.cpp | ||
CGExprComplex.cpp | ||
CGExprConstant.cpp | ||
CGExprScalar.cpp | ||
CGLoopInfo.cpp | ||
CGLoopInfo.h | ||
CGObjC.cpp | ||
CGObjCGNU.cpp | ||
CGObjCMac.cpp | ||
CGObjCRuntime.cpp | ||
CGObjCRuntime.h | ||
CGOpenCLRuntime.cpp | ||
CGOpenCLRuntime.h | ||
CGOpenMPRuntime.cpp | ||
CGOpenMPRuntime.h | ||
CGRecordLayout.h | ||
CGRecordLayoutBuilder.cpp | ||
CGStmt.cpp | ||
CGStmtOpenMP.cpp | ||
CGVTT.cpp | ||
CGVTables.cpp | ||
CGVTables.h | ||
CGValue.h | ||
CMakeLists.txt | ||
CodeGenABITypes.cpp | ||
CodeGenAction.cpp | ||
CodeGenFunction.cpp | ||
CodeGenFunction.h | ||
CodeGenModule.cpp | ||
CodeGenModule.h | ||
CodeGenPGO.cpp | ||
CodeGenPGO.h | ||
CodeGenTBAA.cpp | ||
CodeGenTBAA.h | ||
CodeGenTypes.cpp | ||
CodeGenTypes.h | ||
CoverageMappingGen.cpp | ||
CoverageMappingGen.h | ||
EHScopeStack.h | ||
ItaniumCXXABI.cpp | ||
Makefile | ||
MicrosoftCXXABI.cpp | ||
ModuleBuilder.cpp | ||
README.txt | ||
SanitizerMetadata.cpp | ||
SanitizerMetadata.h | ||
TargetInfo.cpp | ||
TargetInfo.h |
README.txt
IRgen optimization opportunities. //===---------------------------------------------------------------------===// The common pattern of -- short x; // or char, etc (x == 10) -- generates an zext/sext of x which can easily be avoided. //===---------------------------------------------------------------------===// Bitfields accesses can be shifted to simplify masking and sign extension. For example, if the bitfield width is 8 and it is appropriately aligned then is is a lot shorter to just load the char directly. //===---------------------------------------------------------------------===// It may be worth avoiding creation of alloca's for formal arguments for the common situation where the argument is never written to or has its address taken. The idea would be to begin generating code by using the argument directly and if its address is taken or it is stored to then generate the alloca and patch up the existing code. In theory, the same optimization could be a win for block local variables as long as the declaration dominates all statements in the block. NOTE: The main case we care about this for is for -O0 -g compile time performance, and in that scenario we will need to emit the alloca anyway currently to emit proper debug info. So this is blocked by being able to emit debug information which refers to an LLVM temporary, not an alloca. //===---------------------------------------------------------------------===// We should try and avoid generating basic blocks which only contain jumps. At -O0, this penalizes us all the way from IRgen (malloc & instruction overhead), all the way down through code generation and assembly time. On 176.gcc:expr.ll, it looks like over 12% of basic blocks are just direct branches! //===---------------------------------------------------------------------===//