[NFC][CodeGen] Rename method

Extracted from D84652.

[OpenMP] Use the align clause value from 'omp allocate' for globals

Refactor the code that handles the align clause of 'omp allocate' so
it can be used with globals as well as local variables.

Diff

[OpenMP] Use the align clause value from 'omp allocate' for globals

Refactor the code that handles the align clause of 'omp allocate' so
it can be used with globals as well as local variables.

Differential Revision: https://reviews.llvm.org/D126426

show more ...

[clang][OpenMP][DebugInfo] Debug support for TLS variables present in OpenMP consruct

In case of OpenMP programs, thread local variables can be present in
any clause pertaining to OpenMP constructs,

[clang][OpenMP][DebugInfo] Debug support for TLS variables present in OpenMP consruct

In case of OpenMP programs, thread local variables can be present in
any clause pertaining to OpenMP constructs, as we know that compiler
generates artificial functions and in some cases values are passed to
those artificial functions thru parameters. For an example, if thread
local variable is present in copyin clause (testcase attached with the
patch), parameter with same name is generated as parameter to artificial
function. When user inquires the thread Local variable, its debug info
is hidden by the parameter. User never gets the actual TLS variable
when inquires it, instead gets the artificial parameter.

Current patch suppresses the debug info for such artificial parameter to
enable correct debugging of TLS variables.

Reviewed By: aprantl

Differential Revision: https://reviews.llvm.org/D123787

show more ...

Fix size of flexible array initializers, and re-enable assertions.

In D123649, I got the formula for getFlexibleArrayInitChars slightly
wrong: the flexible array elements can be contained in the tai

Fix size of flexible array initializers, and re-enable assertions.

In D123649, I got the formula for getFlexibleArrayInitChars slightly
wrong: the flexible array elements can be contained in the tail padding
of the struct. Fix the formula to account for that.

With the fixed formula, we run into another issue: in some cases, we
were emitting extra padding for flexible arrray initializers. Fix
CGExprConstant so it uses a packed struct when necessary, to avoid this
extra padding.

Differential Revision: https://reviews.llvm.org/D123826

show more ...

Comment out assertions about initializer size added in D123649.

They're causing failures in LLVM test-suite. Added some regression
tests that explain the issue.

Allow flexible array initialization in C++.

Flexible array initialization is a C/C++ extension implemented in many
compilers to allow initializing the flexible array tail of a struct type
that conta

Allow flexible array initialization in C++.

Flexible array initialization is a C/C++ extension implemented in many
compilers to allow initializing the flexible array tail of a struct type
that contains a flexible array. In clang, this is currently restricted
to C. But this construct is used in the Microsoft SDK headers, so I'd
like to extend it to C++.

For now, this doesn't handle dynamic initialization; probably not hard
to implement, but it's extra code, and I don't think it's necessary for
the expected uses. And we explicitly fail out of constant evaluation.

I've added some additional code to assert that initializers have the
correct size, with or without flexible array init. This might catch
issues unrelated to flexible array init.

Differential Revision: https://reviews.llvm.org/D123649

show more ...

[Clang] Implement __builtin_source_location.

This builtin returns the address of a global instance of the
`std::source_location::__impl` type, which must be defined (with an
appropriate shape) befor

[Clang] Implement __builtin_source_location.

This builtin returns the address of a global instance of the
`std::source_location::__impl` type, which must be defined (with an
appropriate shape) before calling the builtin.

It will be used to implement std::source_location in libc++ in a
future change. The builtin is compatible with GCC's implementation,
and libstdc++'s usage. An intentional divergence is that GCC declares
the builtin's return type to be `const void*` (for
ease-of-implementation reasons), while Clang uses the actual type,
`const std::source_location::__impl*`.

In order to support this new functionality, I've also added a new
'UnnamedGlobalConstantDecl'. This artificial Decl is modeled after
MSGuidDecl, and is used to represent a generic concept of an lvalue
constant with global scope, deduplicated by its value. It's possible
that MSGuidDecl itself, or some of the other similar sorts of things
in Clang might be able to be refactored onto this more-generic
concept, but there's enough special-case weirdness in MSGuidDecl that
I gave up attempting to share code there, at least for now.

Finally, for compatibility with libstdc++'s <source_location> header,
I've added a second exception to the "cannot cast from void* to T* in
constant evaluation" rule. This seems a bit distasteful, but feels
like the best available option.

Reviewers: aaron.ballman, erichkeane

Differential Revision: https://reviews.llvm.org/D120159

show more ...

[CodeGen] Avoid some pointer element type accesses

[CodeGen] Rename deprecated Address constructor

To make uses of the deprecated constructor easier to spot, and to
ensure that no new uses are introduced, rename it to
Address::deprecated().

While d

[CodeGen] Rename deprecated Address constructor

To make uses of the deprecated constructor easier to spot, and to
ensure that no new uses are introduced, rename it to
Address::deprecated().

While doing the rename, I've filled in element types in cases
where it was relatively obvious, but we're still left with 135
calls to the deprecated constructor.

show more ...

[CGBuilder] Remove CreateBitCast() method

Use CreateElementBitCast() instead, or don't work on Address
where not necessary.

[CodeGen] Make element type in emitArrayDestroy() predictable

When calling emitArrayDestroy(), the pointer will usually have
ConvertTypeForMem(EltType) as the element type, as one would expect.
Howe

[CodeGen] Make element type in emitArrayDestroy() predictable

When calling emitArrayDestroy(), the pointer will usually have
ConvertTypeForMem(EltType) as the element type, as one would expect.
However, globals with initializers sometimes don't use the same
types as values normally would, e.g. here the global uses
{ double, i32 } rather than %struct.T as element type.

Add an early cast to the global destruction path to avoid this
special case. The cast would happen lateron anyway, it only gets
moved to an earlier point.

Differential Revision: https://reviews.llvm.org/D116219

show more ...

[CodeGen] Avoid one more pointer element type access

The number of elements is always a SizeTy here.

[CodeGen] Avoid more pointer element type accesses

This is enough to build sqlite3 with opaque pointers.

[CodeGen] Always update map entry after adding initializer

With opaque pointers the pointer cast may be a no-op, such that
var and castedAddr are the same. However, we still need to update
the map e

[CodeGen] Always update map entry after adding initializer

With opaque pointers the pointer cast may be a no-op, such that
var and castedAddr are the same. However, we still need to update
the map entry as the underlying global changed. We could explicitly
check whether the global was replaced, but we may as well just
always update the entry.

show more ...

[CodeGen] Avoid more pointer element type accesses

[CodeGen] Avoid some pointer element type accesses

Revert "[clang][DebugInfo] Allow function-local statics and types to be scoped within a lexical block"

This reverts commit e403f4fdc88322201040f2bee7b328e8a78e2f7f because it
breaks TestSetData.py o

Revert "[clang][DebugInfo] Allow function-local statics and types to be scoped within a lexical block"

This reverts commit e403f4fdc88322201040f2bee7b328e8a78e2f7f because it
breaks TestSetData.py on GreenDragon:

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/39089/

show more ...

[clang][DebugInfo] Allow function-local statics and types to be scoped within a lexical block

This is almost a reincarnation of https://reviews.llvm.org/D15977 originally
implemented by Amjad Aboud.

[clang][DebugInfo] Allow function-local statics and types to be scoped within a lexical block

This is almost a reincarnation of https://reviews.llvm.org/D15977 originally
implemented by Amjad Aboud. It was discussed on llvm-dev [0], committed
with its backend counterpart [1], but finally reverted [2].

This patch makes clang to emit debug info for function-local static variables,
records (classes, structs and unions) and typdefs correctly scoped if
those function-local entites defined within a lexical (bracketed) block.

Before this patch, clang emits all those entities directly scoped in
DISubprogram no matter where they were really defined, causing
debug info loss (reported several times in [3], [4], [5]).

[0] https://lists.llvm.org/pipermail/llvm-dev/2015-November/092551.html
[1] https://reviews.llvm.org/rG30e7a8f694a19553f64b3a3a5de81ce317b9ec2f
[2] https://reviews.llvm.org/rGdc4531e552af6c880a69d226d3666756198fbdc8
[3] https://bugs.llvm.org/show_bug.cgi?id=19238
[4] https://bugs.llvm.org/show_bug.cgi?id=23164
[5] https://bugs.llvm.org/show_bug.cgi?id=44695

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D113743

show more ...

In spir functions, llvm.dbg.declare intrinsics created
for parameters and locals need to refer to the stack
allocation in the alloca address space.

Reland [IR] Increase max alignment to 4GB

Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bi

Reland [IR] Increase max alignment to 4GB

Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945.

This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits.
We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now.

The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field.

Updating clang's max allowed alignment will come in a future patch.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D110451

show more ...

Revert "Reland [IR] Increase max alignment to 4GB"

This reverts commit 8d64314ffea55f2ad94c1b489586daa8ce30f451.

Reland [IR] Increase max alignment to 4GB

Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bi

Reland [IR] Increase max alignment to 4GB

Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945.

This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits.
We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now.

The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field.

Updating clang's max allowed alignment will come in a future patch.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D110451

show more ...

Revert "[IR] Increase max alignment to 4GB"

This reverts commit df84c1fe78130a86445d57563dea742e1b85156a.

Breaks some bots

[IR] Increase max alignment to 4GB

Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are

[IR] Increase max alignment to 4GB

Currently the max alignment representable is 1GB, see D108661.
Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945.

This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits.
We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now.

The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field.

Updating clang's max allowed alignment will come in a future patch.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D110451

show more ...

[clang] NFC: change uses of `Expr->getValueKind` into `is?Value`

Signed-off-by: Matheus Izvekov <[email protected]>

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D100733