Changes in Address.h

c070d5ce - [CGOpenMPRuntime] Remove uses of deprecated Address constructor

Wed, 23 Mar 2022 11:14:39 +0000

[CGOpenMPRuntime] Remove uses of deprecated Address constructorAnd as these are the last remaining uses, also remove theconstructor itself. List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

50650766 - [CodeGen] Rename deprecated Address constructor

Wed, 16 Feb 2022 15:38:11 +0000

[CodeGen] Rename deprecated Address constructorTo make uses of the deprecated constructor easier to spot, and toensure that no new uses are introduced, rename it toAddress::deprecated().While doing the rename, I've filled in element types in caseswhere it was relatively obvious, but we're still left with 135calls to the deprecated constructor. List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

eee97f16 - [clang] Use proper type to left shift after D117262

Thu, 27 Jan 2022 01:54:37 +0000

[clang] Use proper type to left shift after D117262Causing warnings likewarning C4334: '<<': result of 32-bit shift implicitly converted to 64 bitsas reported in D117262. List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

6a953d93 - [clang] Fix -Wsubobject-linkage after D117262

Wed, 26 Jan 2022 19:41:47 +0000

[clang] Fix -Wsubobject-linkage after D117262/home/buildbot/llvm-avr-linux/llvm-avr-linux/llvm/clang/lib/CodeGen/Address.h:76:7: warning: 'clang::CodeGen::Address' has a field 'clang::CodeGen::Address::A' whose type uses the anonymous namespace [-Wsubobject-linkage]https://lab.llvm.org/buildbot/#/builders/112/builds/12047 List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

b1613f05 - [NFC] Store Address's alignment into PointerIntPairs

Fri, 14 Jan 2022 00:30:29 +0000

[NFC] Store Address's alignment into PointerIntPairsThis mitigates the extra memory caused by D115725.On 32-bit arches where we only have 2 bits per PointerIntPair we fallback to simply storing alignment separately.Reviewed By: rnk, nikicDifferential Revision: https://reviews.llvm.org/D117262 List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

e751d978 - [CodeGen] Avoid some pointer element type accesses

Mon, 20 Dec 2021 15:17:27 +0000

[CodeGen] Avoid some pointer element type accessesThis avoids some pointer element type accesses when compilingC++ code. List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

c3b624a1 - [CodeGen] Avoid deprecated ConstantAddress constructor

Wed, 15 Dec 2021 08:38:48 +0000

[CodeGen] Avoid deprecated ConstantAddress constructorChange all uses of the deprecated constructor to pass theelement type explicitly and drop it.For cases where the correct element type was not immediatelyobvious to me or would require a slightly larger change I'mfalling back to explicitly calling getPointerElementType() for now. List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

abbc2e99 - [CodeGen] Store ElementType in Address

Tue, 14 Dec 2021 13:37:23 +0000

[CodeGen] Store ElementType in AddressExplicitly track the pointer element type in Address, rather thanderiving it from the pointer type, which will no longer be possiblewith opaque pointers. This just adds the basic facility, for noweverything is still going through the deprecated constructors.I had to adjust one place in the LValue implementation to satisfythe new assertions: Global registers are represented as aMetadataAsValue, which does not have a pointer type. We shouldavoid using Address in this case.This implements a part of D103465.Differential Revision: https://reviews.llvm.org/D115725 List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

b81450af - [CodeGen] Add std:: qualifier

Tue, 14 Dec 2021 11:17:55 +0000

[CodeGen] Add std:: qualifierHopefully addresses the buildbot failures. List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

b8d121eb - [CodeGen] Require use of Address::invalid() for invalid address (NFC)

Mon, 13 Dec 2021 13:23:21 +0000

[CodeGen] Require use of Address::invalid() for invalid address (NFC)This no longer allows creating an invalid Address through the regularconstructor. There were only two places that did this (AggValueSlotand EHCleanupScope) which did this by converting a potential nullptrinto an Address. I've fixed both of these by directly storing anAddress instead.This is intended as a bit of preliminary cleanup for D103465.Differential Revision: https://reviews.llvm.org/D115630 List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

2946cd70 - Update the file headers across all of the LLVM projects in the monorepo

Sat, 19 Jan 2019 08:50:56 +0000

Update the file headers across all of the LLVM projects in the monorepoto reflect the new license.We understand that people may be surprised that we're moving the headerentirely to discuss the new license. We checked this carefully with theFoundation's lawyer and we believe this is the correct approach.Essentially, all code in the project is now made available by the LLVMproject under our new license, so you will see that the license headersinclude that license only. Some of our contributors have contributedcode under our old license, and accordingly, we have retained a copy ofour old license notice in the top-level files in each project andrepository.llvm-svn: 351636 List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

ad609d56 - Work around build failure due to GCC 4.8.1 bug. We don't completely understand

Tue, 02 Feb 2016 23:11:49 +0000

Work around build failure due to GCC 4.8.1 bug. We don't completely understandthe details of the bug, but avoiding overloading llvm::cast with anotherfunction template sidesteps it.See gcc.gnu.org/PR58022 for details of the bug, and llvm.org/PR26362 for morebackgound on how it manifested in Clang. Patch by Igor Sugak!llvm-svn: 259598 List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

d0637bd1 - PR25368: Replace workaround for build failure with modules enabled with a fix

Thu, 05 Nov 2015 21:16:22 +0000

PR25368: Replace workaround for build failure with modules enabled with a fixfor the root cause. The 'using llvm::isa;' declaration in Basic/LLVM.h onlypulls the declarations of llvm::isa that were declared prior to it intonamespace clang. In a modules build, this is a hermetic set of just thedeclarations from LLVM. In a non-modules build, we happened to also pull thedeclaration from lib/CodeGen/Address.h into namespace clang, which made thecode in question accidentally compile.llvm-svn: 252211 List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h

7f416cc4 - Compute and preserve alignment more faithfully in IR-generation.

Tue, 08 Sep 2015 08:05:57 +0000

Compute and preserve alignment more faithfully in IR-generation.Introduce an Address type to bundle a pointer value with analignment. Introduce APIs on CGBuilderTy to work with Addressvalues. Change core APIs on CGF/CGM to traffic in Address whereappropriate. Require alignments to be non-zero. Update a tonof code to compute and propagate alignment information.As part of this, I've promoted CGBuiltin's EmitPointerWithAlignmenthelper function to CGF and made use of it in a number of places inthe expression emitter.The end result is that we should now be significantly more correctwhen performing operations on objects that are locally known tobe under-aligned. Since alignment is not reliably tracked in thetype system, there are inherent limits to this, but at least weare no longer confused by standard operations like derived-to-baseconversions and array-to-pointer decay. I've also fixed a largenumber of bugs where we were applying the complete-object alignmentto a pointer instead of the non-virtual alignment, although most ofthese were hidden by the very conservative approach we took withmember alignment.Also, because IRGen now reliably asserts on zero alignments, weshould no longer be subject to an absurd but frustrating recurringbug where an incomplete type would report a zero alignment and thenwe'd naively do a alignmentAtOffset on it and emit code using analignment equal to the largest power-of-two factor of the offset.We should also now be emitting much more aggressive alignmentattributes 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 existingcode-generation pattern in order to more effectively usethe Address APIs. For the most part, this seems to be a strictimprovement, like doing pointer arithmetic with GEPs instead ofptrtoint. 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 Iapologize.ABIArgInfo now always carries the assumed alignment of indirect andindirect byval arguments. In order to cut down on what was alreadya dauntingly large patch, I changed the code to never set alignattributes in the IR on non-byval indirect arguments. That is,we still generate code which assumes that indirect arguments havethe given alignment, but we don't express this information to thebackend except where it's semantically required (i.e. on byvals).This is likely a minor regression for those targets that did providethis information, but it'll be trivial to add it back in a laterpatch.I partially punted on applying this work to CGBuiltin. Pleasedo not add more uses of the CreateDefaultAligned{Load,Store}APIs; they will be going away eventually.llvm-svn: 246985 List of files: /llvm-project-15.0.7/clang/lib/CodeGen/Address.h