CWD is queried in clang driver and passed to clang cc1 via flags when
needed. Respect the cc1 flags and do not repeated checking current
working directory in CodeGen.
This reverts commit cd826d6e840ed33ad88458c862da5f9fcc6e908c and relands
27c1aa9b9cf9e0b14211758ff8f7d3aaba24ffcf
This fixes#104765
I tweaked the code to avoid an OOB.
This extends https://github.com/llvm/llvm-project/pull/138577 to more UBSan checks, by changing SanitizerDebugLocation (formerly SanitizerScope) to add annotations if enabled for the specified ordinals.
Annotations will use the ordinal name if there is exactly one ordinal specified in the SanitizerDebugLocation; otherwise, it will use the handler name.
Updates the tests from https://github.com/llvm/llvm-project/pull/141814.
---------
Co-authored-by: Vitaly Buka <vitalybuka@google.com>
The IR now includes a global variable for the debugger that holds
the address of the vtable.
Now every class that contains virtual functions, has a static
member (marked as artificial) that identifies where that vtable
is loaded in memory. The unmangled name is '_vtable$'.
This new symbol will allow a debugger to easily associate
classes with the physical location of their VTables using
only the DWARF information. Previously, this had to be done
by searching for ELF symbols with matching names; something
that was time-consuming and error-prone in certain edge cases.
This is a scoped helper similar to ApplyDebugLocation that creates a new source
location atom group which instructions can be added to.
A source atom is a source construct that is "interesting" for debug stepping
purposes. We use an atom group number to track the instruction(s) that implement
the functionality for the atom, plus backup instructions/source locations.
This patch is part of a stack that teaches Clang to generate Key Instructions
metadata for C and C++.
RFC:
https://discourse.llvm.org/t/rfc-improving-is-stmt-placement-for-better-interactive-debugging/82668
The feature is only functional in LLVM if LLVM is built with CMake flag
LLVM_EXPERIMENTAL_KEY_INSTRUCTIONs. Eventually that flag will be removed.
This reverts commit 27c1aa9b9cf9e0b14211758ff8f7d3aaba24ffcf.
See comments on PR. After this change, Clang now asserts like this:
clang: ../llvm/include/llvm/IR/Metadata.h:1435: const MDOperand &llvm::MDNode::getOperand(unsigned int) const: Assertion `I < getNumOperands() && "Out of range"' failed.
...
#8 0x000055f345c4e4cb clang::CodeGen::CGDebugInfo::getOrCreateInstanceMethodType()
#9 0x000055f345c5ba4f clang::CodeGen::CGDebugInfo::EmitFunctionDecl()
#10 0x000055f345b52519 clang::CodeGen::CodeGenModule::EmitExternalFunctionDeclaration()
This is due to pre-existing jankiness in the way BPF emits extra
declarations for debug info, but we should rollback and then fix forward.
Fixes issue #104765: When creating a virtual destructor with an
artificial "vtt" argument, the type of "vtt" was previously missing in
the `DISubroutineType` `types` array.
This commit fixes this behavior and adds a regression test.
This PR fix the debug infor generation for RWBuffer types.
- This implements the [same fix as
DXC](https://github.com/microsoft/DirectXShaderCompiler/pull/6296).
- Adds the HLSLAttributedResource debug info generation
Closes#118523
---------
Co-authored-by: Joao Saffran <jderezende@microsoft.com>
Co-authored-by: joaosaffran <joao.saffran@microsoft.com>
HLSL has a set of intangible types which are described in in the
[draft HLSL Specification
(**[Basic.types]**)](https://microsoft.github.io/hlsl-specs/specs/hlsl.pdf):
There are special implementation-defined types such as handle types,
which fall into a category of standard intangible types. Intangible
types are types that have no defined object representation or value
representation, as such the size is unknown at compile time.
A class type T is an intangible class type if it contains an base
classes or members of intangible class type, standard intangible type,
or arrays of such types. Standard intangible types and intangible class
types are collectively called intangible
types([9](https://microsoft.github.io/hlsl-specs/specs/hlsl.html#Intangible)).
This PR implements one standard intangible type `__hlsl_resource_t`
and sets up the infrastructure that will make it easier to add more
in the future, such as samplers or raytracing payload handles. The
HLSL intangible types are declared in
`clang/include/clang/Basic/HLSLIntangibleTypes.def` and this file is
included with related macro definition in most places that require edits
when a new type is added.
The new types are added as keywords and not typedefs to make sure they
cannot be redeclared, and they can only be declared in builtin implicit
headers. The `__hlsl_resource_t` type represents a handle to a memory
resource and it is going to be used in builtin HLSL buffer types like this:
template <typename T>
class RWBuffer {
[[hlsl::contained_type(T)]]
[[hlsl::is_rov(false)]]
[[hlsl::resource_class(uav)]]
__hlsl_resource_t Handle;
};
Part 1/3 of llvm/llvm-project#90631.
---------
Co-authored-by: Justin Bogner <mail@justinbogner.com>
The builtin causes the program to stop its execution abnormally and
shows a human-readable description of the reason for the termination
when a debugger is attached or in a symbolicated crash log.
The motivation for the builtin is explained in the following RFC:
https://discourse.llvm.org/t/rfc-adding-builtin-verbose-trap-string-literal/75845
clang's CodeGen lowers the builtin to `llvm.trap` and emits debugging
information that represents an artificial inline frame whose name
encodes the category and reason strings passed to the builtin.
This patch adds a new builtin type for AMDGPU's buffer rsrc data type,
which is effectively an AS 8 pointer. This is needed because we'd like
to expose certain intrinsics to users via builtins which take buffer
rsrc as argument.
Currently we use DW_OP_plus_uconst to handle the bitfield offset and
handle the bitfield size by choosing a type size that matches, but this
doesn't work if either offset or size aren't byte-aligned. Extracting
the bits using DW_OP_LLVM_extract_bits means we can handle any kind of
offset or size.
This is a different implementation to #94100, which has been reverted.
When -fdebug-info-for-profiling is specified, for any Load expression if
the pointer operand is not a declared variable, clang will emit debug
info describing the type of the pointer operand (which can be an
intermediate expr)
The option is causing the binary output to be different when compiled
under `-O0`, because it introduce dbg.declare on pseudovariables. Going
to change this implementation to use dbg.value instead.
This is another attempt to land #81545, which was reverted.
Fixed test case by adding a target triple so that clang generates the same IR for all platforms
This reverts commit aeccfee348c717165541d8d895b9b0cdfe31415c, and dependents:
Revert "[NFC] Fix PPC buildbot failure https://lab.llvm.org/buildbot/#/builders/230/builds/29066"
This reverts commit 2b1d1c51f6e321267cc86e9db7808298c59caf0e.
Revert "Fix test - remove unnecessary/incorrect `-S`, in favor of `-emit-llvm`"
This reverts commit ea1ecb50fa831583241fc531153bd2c072955d29.
The test is failing on MacOs and Windows
Such expression does not correspond to a variable in the source code
thus does not have a debug location. When the user collects perf data on
the program, if the intermediate memory load instruction is sampled, it
could not be attributed to any variable/class member, which causes the
sampling results to be under-counted.
This patch adds an option `-fdebug_info_for_pointer_type` to generate a
psuedo variable and its debug info for intermediate expression with
pointer dereferencing, so that perf data collected on the instruction of
that expression can be attributed to the correct class member.
This is a prototype so comments are needed.
Fix issue https://github.com/llvm/llvm-project/issues/54624
Add front end flags -gtemplate-alias (also a cc1 flag) and -gno-template-alias
to enable/disable usage of the feature. It's enabled by default in the front
end for SCE debugger tuning only.
GCC emits DW_TAG_typedef for template aliases (as does Clang with this feature
disabled), and GDB and LLDB appear not to support DW_TAG_template_alias.
The -Xclang option -gsimple-template-names=mangled is treated the same as
=full, which is not a regression from current behaviour for template
aliases.
The current implementation omits defaulted arguments and as a consequence
also omits empty parameter packs that come after defaulted arguments. Again,
this isn't a regression as the DW_TAG_typedef name doesn't contain defaulted
arguments.
LLVM support added in https://github.com/llvm/llvm-project/pull/88943
Added template-alias.cpp - Check the metadata construction & interaction with
-gsimple-template-names.
Added variadic-template-alias.cpp - Check template parameter packs work.
Added defaulted-template-alias.cpp - Check defaulted args (don't) work.
Modified debug-options.c - Check Clang generates correct cc1 flags.
This commit reverts the changes in
https://github.com/llvm/llvm-project/pull/71780 and all of its follow-up
patches.
We got reports of the `.debug_names/.debug_gnu_pubnames/gdb_index/etc.`
sections growing by a non-trivial amount for some large projects. While
GCC emits definitions for static data member constants into the Names
index, they do so *only* for explicitly `constexpr` members. We were
indexing *all* constant-initialized const-static members, which is
likely where the significant size difference comes from. However, only
emitting explicitly `constexpr` variables into the index doesn't seem
like a good way forward, since from clang's perspective `const`-static
integrals are `constexpr` too, and that shouldn't be any different in
the debug-info component. Also, as new code moves to `constexpr` instead
of `const` static for constants, such solution would just delay the
growth of the Names index.
To prevent the size regression we revert to not emitting definitions for
static data-members that have no location.
To support access to such constants from LLDB we'll most likely have to
have to make LLDB find the constants by looking at the containing class
first.
This patch relands https://github.com/llvm/llvm-project/pull/70639
It was reverted because under certain conditions we triggered an
assertion
in `DIBuilder`. Specifically, in the original patch we called
`EmitGlobalVariable`
at the end of `CGDebugInfo::finalize`, after all the temporary `DIType`s
have
been uniqued. With limited debug-info such temporary nodes would be
created
more frequently, leaving us with non-uniqued nodes by the time we got to
`DIBuilder::finalize`; this violated its pre-condition and caused
assertions to trigger.
To fix this, the latest iteration of the patch moves
`EmitGlobalVariable` to the
beginning of `CGDebugInfo::finalize`. Now, when we create a temporary
`DIType` node as a result of emitting a variable definition, it will get
uniqued
in time. A test-case was added for this scenario.
We also now don't emit a linkage name for non-locationed constants since
LLDB doesn't make use of it anyway.
Original commit message:
"""
When an LLDB user asks for the value of a static data member, LLDB
starts
by searching the Names accelerator table for the corresponding variable
definition DIE. For static data members with out-of-class definitions
that
works fine, because those get represented as global variables with a
location
and making them eligible to be added to the Names table. However,
in-class
definitions won’t get indexed because we usually don't emit global
variables
for them. So in DWARF we end up with a single `DW_TAG_member` that
usually holds the constant initializer. But we don't get a corresponding
CU-level `DW_TAG_variable` like we do for out-of-class definitions.
To make it more convenient for debuggers to get to the value of inline
static data
members, this patch makes sure we emit definitions for static variables
with
constant initializers the same way we do for other static variables.
This also aligns
Clang closer to GCC, which produces CU-level definitions for inline
statics and also
emits these into `.debug_pubnames`.
The implementation keeps track of newly created static data members.
Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with
a
`DW_AT_const_value` for any of those declarations that didn't end up
with a
definition in the `DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x0000008d: DW_TAG_member
DW_AT_name ("i")
DW_AT_type (0x00000062 "const int")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x0000009a: DW_TAG_variable
DW_AT_specification (0x0000008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
This patch also drops the `DW_AT_const_value` off of the declaration
since we
now always have it on the definition. This ensures that the
`DWARFParallelLinker`
can type-merge class with static members where we couldn't attach the
constant
on the declaration in some CUs.
"""
Dependent changes:
* https://github.com/llvm/llvm-project/pull/71800
This casued asserts:
llvm/lib/IR/Metadata.cpp:689:
void llvm::MDNode::resolve(): Assertion `isUniqued() && "Expected this to be uniqued"' failed.
See comments on the PR.
This also reverts the dependent follow-up commits, see below.
> When an LLDB user asks for the value of a static data member, LLDB
> starts by searching the Names accelerator table for the corresponding
> variable definition DIE. For static data members with out-of-class
> definitions that works fine, because those get represented as global
> variables with a location and making them eligible to be added to the
> Names table. However, in-class definitions won<E2><80><99>t get indexed because
> we usually don't emit global variables for them. So in DWARF we end
> up with a single `DW_TAG_member` that usually holds the constant
> initializer. But we don't get a corresponding CU-level
> `DW_TAG_variable` like we do for out-of-class definitions.
>
> To make it more convenient for debuggers to get to the value of
> inline static data members, this patch makes sure we emit definitions
> for static variables with constant initializers the same way we do
> for other static variables. This also aligns Clang closer to GCC,
> which produces CU-level definitions for inline statics and also
> emits these into `.debug_pubnames`.
>
> The implementation keeps track of newly created static data members.
> Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable`
> with a `DW_AT_const_value` for any of those declarations that didn't
> end up with a definition in the `DeclCache`.
>
> The newly emitted `DW_TAG_variable` will look as follows:
> ```
> 0x0000007b: DW_TAG_structure_type
> DW_AT_calling_convention (DW_CC_pass_by_value)
> DW_AT_name ("Foo")
> ...
>
> 0x0000008d: DW_TAG_member
> DW_AT_name ("i")
> DW_AT_type (0x00000062 "const int")
> DW_AT_external (true)
> DW_AT_declaration (true)
> DW_AT_const_value (4)
>
> Newly added
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>
> 0x0000009a: DW_TAG_variable
> DW_AT_specification (0x0000008d "i")
> DW_AT_const_value (4)
> DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
> ```
>
> This patch also drops the `DW_AT_const_value` off of the declaration
> since we now always have it on the definition. This ensures that the
> `DWARFParallelLinker` can type-merge class with static members where
> we couldn't attach the constant on the declaration in some CUs.
This reverts commit 7c3707aea8a6f1fc245ad2862982b8a51b6c0fea.
This reverts commit cab0a19467ac2e6e1e022087f4b6cb90d55da040.
This reverts commit 317481b3c8b34b0c3f106c514e6aa39b70886110.
This reverts commit 15fc809404d4715822e5349b76dcca50eb100eec.
This reverts commit 470de2bbec7f5fdd199775aa99c68ac76f4d5c74.
When an LLDB user asks for the value of a static data member, LLDB
starts by searching the Names accelerator table for the corresponding
variable definition DIE. For static data members with out-of-class
definitions that works fine, because those get represented as global
variables with a location and making them eligible to be added to the
Names table. However, in-class definitions won’t get indexed because
we usually don't emit global variables for them. So in DWARF we end
up with a single `DW_TAG_member` that usually holds the constant
initializer. But we don't get a corresponding CU-level
`DW_TAG_variable` like we do for out-of-class definitions.
To make it more convenient for debuggers to get to the value of
inline static data members, this patch makes sure we emit definitions
for static variables with constant initializers the same way we do
for other static variables. This also aligns Clang closer to GCC,
which produces CU-level definitions for inline statics and also
emits these into `.debug_pubnames`.
The implementation keeps track of newly created static data members.
Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable`
with a `DW_AT_const_value` for any of those declarations that didn't
end up with a definition in the `DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x0000008d: DW_TAG_member
DW_AT_name ("i")
DW_AT_type (0x00000062 "const int")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x0000009a: DW_TAG_variable
DW_AT_specification (0x0000008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
This patch also drops the `DW_AT_const_value` off of the declaration
since we now always have it on the definition. This ensures that the
`DWARFParallelLinker` can type-merge class with static members where
we couldn't attach the constant on the declaration in some CUs.
This reverts commit 4909814c08fdf4ec8bd9dad4f157d03de7c3c800.
Following LLDB patch had to be reverted due to Linux test failures:
```
ef3febadf606c2fc4f1ad8d85a7ecdde16e4cbb3
```
Since without that LLDB patch the LLDB tests would fail, revert
this clang patch for now.
When an LLDB user asks for the value of a static data member, LLDB
starts by
searching the Names accelerator table for the corresponding variable
definition
DIE. For static data members with out-of-class definitions that works
fine,
because those get represented as global variables with a location and
making them
eligible to be added to the Names table. However, in-class definitions
won’t get
indexed because we usually don't emit global variables for them. So in
DWARF
we end up with a single `DW_TAG_member` that usually holds the constant
initializer.
But we don't get a corresponding CU-level `DW_TAG_variable` like we do
for
out-of-class definitions.
To make it more convenient for debuggers to get to the value of inline
static data members,
this patch makes sure we emit definitions for static variables with
constant initializers
the same way we do for other static variables. This also aligns Clang
closer to GCC, which
produces CU-level definitions for inline statics and also emits these
into `.debug_pubnames`.
The implementation keeps track of newly created static data members.
Then in
`CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with a
`DW_AT_const_value` for
any of those declarations that didn't end up with a definition in the
`DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x0000008d: DW_TAG_member
DW_AT_name ("i")
DW_AT_type (0x00000062 "const int")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x0000009a: DW_TAG_variable
DW_AT_specification (0x0000008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
This patch also drops the `DW_AT_const_value` off of the declaration since we now always have it on the definition. This ensures that the `DWARFParallelLinker` can type-merge class with static members where we couldn't attach the constant on the declaration in some CUs.
This patch factors out the code to create a DIExpression from an APValue
into a separate helper function.
This will be useful in a follow-up patch where we re-use this logic
elsewhere.
Pre-requisite for https://github.com/llvm/llvm-project/pull/70639
D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.
This reverts commit 5956648fc3ba11dd6b0d0f2d1d9b923e7f80f247.
There was a string lifetime issue that is now corrected.
Differential Revision: https://reviews.llvm.org/D156571
D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.
This reverts commit 21e7f73494663814e0296066895dfacdebfac6d4.
I'm unable to find a reason for the memory management issues
that caused the revert, so trying again.
D155991 changed the file lookup to do a full string compare on the
filename; however, this added ~0.5% to compile time with -g.
Go back to the previous pointer-based lookup, but capture the main
file's checksum as well as its name to use when creating the extra
DIFile entry. This causes all entries to be consistent and also
avoids computing the checksum twice.
Differential revision: https://reviews.llvm.org/D156571
In cases where a structured binding declaration is made to a struct with
bitfields:
struct A {
unsigned int x : 16;
unsigned int y : 16;
} g;
auto [a, b] = g; // structured binding declaration
Clang assigns the 'unsigned int' DWARF base type to 'a' and 'b' because
this is their deduced C++ type in the structured binding declaration.
However, their actual type in memory is 'unsigned short' as they have 16
bits allocated for each.
This is a problem for debug information consumers: if the debug
information for 'a' has the 'unsigned int' base type, a debugger will
assume it has 4 bytes, whereas it actually has a length of 2, resulting
in a read (or write) past its length.
This patch mimics GCC's behaviour: in case of structured bindings to
bitfields, the binding declaration's DWARF base type is of the target's
integer type with the same bitwidth as the bitfield.
If no suitable integer type is found in the target, no debug information
is emitted anymore in order to prevent wrong debug output.
Reviewed By: tmatheson
Differential Revision: https://reviews.llvm.org/D157479
The DIFile cache was keyed on a string pointer instead of string content,
which was causing misses and resulted in an entry without a checksum.
In DWARF v5 if any checksum is missing, we can't write any to the output
file, so this had consequences.
Fixes https://github.com/llvm/llvm-project/issues/63955
Differential revision: https://reviews.llvm.org/D155991
This patch adds copy/move assignment operator to the class which has user-defined copy/move constructor.
Reviewed By: tahonermann, NoQ, aaronpuchert
Differential Revision: https://reviews.llvm.org/D150411
For
`clang -c -g -fdebug-prefix-map=a/b=y -fdebug-prefix-map=a=x a/b/c.c`,
we apply the longest prefix substitution, but
GCC has always been picking the last applicable option (`a=x`, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591).
I feel that GCC's behavior is reasonable given the convention that the last
value wins for the same option.
Before D49466, Clang appeared to apply the shortest prefix substitution,
which likely made the least sense.
Reviewed By: #debug-info, scott.linder
Differential Revision: https://reviews.llvm.org/D148975
With this patch, whenever we emit a `DW_AT_type` for some declaration
and the type is a template class with a `clang::PreferredNameAttr`, we
will emit the typedef that the attribute refers to instead. I.e.,
```
0x123 DW_TAG_variable
DW_AT_name "var"
DW_AT_type (0x123 "basic_string<char>")
0x124 DW_TAG_structure_type
DW_AT_name "basic_string<char>"
```
...becomes
```
0x123 DW_TAG_variable
DW_AT_name "var"
DW_AT_type (0x124 "std::string")
0x124 DW_TAG_structure_type
DW_AT_name "basic_string<char>"
0x125 DW_TAG_typedef
DW_AT_name "std::string"
DW_AT_type (0x124 "basic_string<char>")
```
We do this by returning the preferred name typedef `DIType` when
we create a structure definition. In some cases, e.g., with `-gmodules`,
we don't complete the structure definition immediately but do so later
via `completeClassData`, which overwrites the `TypeCache`. In such cases
we don't actually want to rewrite the cache with the preferred name. We
handle this by returning both the definition and the preferred typedef
from `CreateTypeDefinition` and let the callee decide what to do with
it.
Essentially we set up the types as:
```
TypeCache[Record] => DICompositeType
ReplaceMap[Record] => DIDerivedType(baseType: DICompositeType)
```
For now we keep this behind LLDB tuning.
**Testing**
- Added clang unit-test
- `check-llvm`, `check-clang` pass
- Confirmed that this change correctly repoints
`basic_string` references in some of my test programs.
- Will add follow-up LLDB API tests
Differential Revision: https://reviews.llvm.org/D145803
This patch moves the Debug Options to llvm/Frontend so that it can be shared by Flang as well.
Reviewed By: kiranchandramohan, awarzynski
Differential Revision: https://reviews.llvm.org/D142347
Consider the following sturctures when targetting:
struct foo {
int space[4];
char a : 8;
char b : 8;
char x : 8;
char y : 8;
};
struct bar {
int space[4];
char a : 8;
char b : 8;
char : 0;
char x : 8;
char y : 8;
};
Even if both structs have the same layout in memory, they are handled
differenlty by the AMDGPU ABI.
With the following code:
// clang --target=amdgcn-amd-amdhsa -g -O1 example.c -S
char use_foo(struct foo f) { return f.y; }
char use_bar(struct bar b) { return b.y; }
For use_foo, the 'y' field is passed in v4
; v_ashrrev_i32_e32 v0, 24, v4
; s_setpc_b64 s[30:31]
For use_bar, the 'y' field is passed in v5
; v_bfe_i32 v0, v5, 8, 8
; s_setpc_b64 s[30:31]
To make this distinction, we record a single 0-size bitfield for every member that is preceded
by it.
Reviewed By: probinson
Differential Revision: https://reviews.llvm.org/D144870
This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122215
The commit was reverted due to a regression in debug information of an
optimized code test in lldb. This has since been addressed by:
1. rGf753e5be8239: [LiveDebugValues] Allow EntryValue with OP_deref
expressions
2. rG055f2f04e658: [mem2reg][debuginfo] Handle op_deref when converting
dbg.declare
Differential Revision: https://reviews.llvm.org/D141381
This patch introduces a new type __externref_t that denotes a WebAssembly opaque
reference type. It also implements builtin __builtin_wasm_ref_null_extern(),
that returns a null value of __externref_t. This lays the ground work
for further builtins and reference types.
Differential Revision: https://reviews.llvm.org/D122215
