[clang][DebugInfo] Emit debuginfo for non-constant case value

Currently, clang does not emit debuginfo for the switch stmt
case value if it is an enum value. For example,
$ cat test.c
enum { AA

[clang][DebugInfo] Emit debuginfo for non-constant case value

Currently, clang does not emit debuginfo for the switch stmt
case value if it is an enum value. For example,
$ cat test.c
enum { AA = 1, BB = 2 };
int func1(int a) {
switch(a) {
case AA: return 10;
case BB: return 11;
default: break;
}
return 0;
}
$ llvm-dwarfdump test.o | grep AA
$
Note that gcc does emit debuginfo for the same test case.

This patch added such a support with similar implementation
to CodeGenFunction::EmitDeclRefExprDbgValue(). With this patch,
$ clang -g -c test.c
$ llvm-dwarfdump test.o | grep AA
DW_AT_name ("AA")
$

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

(cherry picked from commit 75be0482a2e2a78fae83f1ca604f4ee20d673796)

show more ...

[CodeGen][inlineasm] assume the flag output of inline asm is boolean value

GCC inline asm document says that
"... the general rule is that the output variable must be a scalar
integer, and the value

[CodeGen][inlineasm] assume the flag output of inline asm is boolean value

GCC inline asm document says that
"... the general rule is that the output variable must be a scalar
integer, and the value is boolean."

Commit e5c37958f901cc9bec50624dbee85d40143e4bca lowers flag output of
inline asm on X86 with setcc, hence it is guaranteed that the flag
is of boolean value. Clang does not support ARM inline asm flag output
yet so nothing need to be worried about ARM.

See "Flag Output" section at
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#OutputOperands

Fixes https://github.com/llvm/llvm-project/issues/56568

Reviewed By: nikic

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

(cherry picked from commit 92c1bc61586c9d6c7bf0c36b1005fe00b4f48cc0)

show more ...

[IR] Don't use blockaddresses as callbr arguments

Following some recent discussions, this changes the representation
of callbrs in IR. The current blockaddress arguments are replaced
with `!` label

[IR] Don't use blockaddresses as callbr arguments

Following some recent discussions, this changes the representation
of callbrs in IR. The current blockaddress arguments are replaced
with `!` label constraints that refer directly to callbr indirect
destinations:

; Before:
%res = callbr i8* asm "", "=r,r,i"(i8* %x, i8* blockaddress(@test8, %foo))
to label %asm.fallthrough [label %foo]
; After:
%res = callbr i8* asm "", "=r,r,!i"(i8* %x)
to label %asm.fallthrough [label %foo]

The benefit of this is that we can easily update the successors of
a callbr, without having to worry about also updating blockaddress
references. This should allow us to remove some limitations:

* Allow unrolling/peeling/rotation of callbr, or any other
clone-based optimizations
(https://github.com/llvm/llvm-project/issues/41834)
* Allow duplicate successors
(https://github.com/llvm/llvm-project/issues/45248)

This is just the IR representation change though, I will follow up
with patches to remove limtations in various transformation passes
that are no longer needed.

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

show more ...

[OpenMP] Initial parsing and semantic support for 'parallel masked taskloop simd' construct

This patch gives basic parsing and semantic support for
"parallel masked taskloop simd" construct introduc

[OpenMP] Initial parsing and semantic support for 'parallel masked taskloop simd' construct

This patch gives basic parsing and semantic support for
"parallel masked taskloop simd" construct introduced in
OpenMP 5.1 (section 2.16.10)

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

show more ...

[OpenMP] Initial parsing and sema support for 'parallel masked taskloop' construct

This patch gives basic parsing and semantic support for
"parallel masked taskloop" construct introduced in
OpenMP 5

[OpenMP] Initial parsing and sema support for 'parallel masked taskloop' construct

This patch gives basic parsing and semantic support for
"parallel masked taskloop" construct introduced in
OpenMP 5.1 (section 2.16.9)

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

show more ...

[OpenMP] Initial parsing and sema support for 'masked taskloop simd' construct

This patch gives basic parsing and semantic support for
"masked taskloop simd" construct introduced in OpenMP 5.1 (sect

[OpenMP] Initial parsing and sema support for 'masked taskloop simd' construct

This patch gives basic parsing and semantic support for
"masked taskloop simd" construct introduced in OpenMP 5.1 (section 2.16.8)

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

show more ...

[OpenMP] Initial parsing and sema support for 'masked taskloop' construct

This patch gives basic parsing and semantic support for "masked taskloop"
construct introduced in OpenMP 5.1 (section 2.16.7

[OpenMP] Initial parsing and sema support for 'masked taskloop' construct

This patch gives basic parsing and semantic support for "masked taskloop"
construct introduced in OpenMP 5.1 (section 2.16.7)

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

show more ...

Stop wrapping GCCAsmStmts inside StmtExprs to destruct temporaries

Instead, just pop the cleanups at the end of the asm statement.

This fixes an assertion failure in BuildStmtExpr. It also fixes a

Stop wrapping GCCAsmStmts inside StmtExprs to destruct temporaries

Instead, just pop the cleanups at the end of the asm statement.

This fixes an assertion failure in BuildStmtExpr. It also fixes a bug
where blocks and C compound literals were destructed at the end of the
asm statement instead of at the end of the enclosing scope.

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

show more ...

[OpenMP] Initial parsing and sema for 'parallel masked' construct

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

[OpenMP] Initial parsing/sema for the 'omp target parallel loop' construct

Adds basic parsing/sema/serialization support for the
#pragma omp target parallel loop directive.

Differential Revision:

[OpenMP] Initial parsing/sema for the 'omp target parallel loop' construct

Adds basic parsing/sema/serialization support for the
#pragma omp target parallel loop directive.

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

show more ...

[Inline-asm] Add diagnosts for unsupported inline assembly arguments

GCC supports power-of-2 size structures for the arguments. Clang supports fewer than GCC. But Clang always crashes for the unsupp

[Inline-asm] Add diagnosts for unsupported inline assembly arguments

GCC supports power-of-2 size structures for the arguments. Clang supports fewer than GCC. But Clang always crashes for the unsupported cases.

This patch adds sema checks to do the diagnosts to solve these crashes.

Reviewed By: jyu2

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

show more ...

[OpenMP] Initial parsing/sema for the 'omp parallel loop' construct

Adds basic parsing/sema/serialization support for the
#pragma omp parallel loop directive.

Differential Revision: https://re

[OpenMP] Initial parsing/sema for the 'omp parallel loop' construct

Adds basic parsing/sema/serialization support for the
#pragma omp parallel loop directive.

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

show more ...

[OpenMP] Initial parsing/sema for the 'omp target teams loop' construct

Adds basic parsing/sema/serialization support for the
#pragma omp target teams loop directive.

Differential Revision: https

[OpenMP] Initial parsing/sema for the 'omp target teams loop' construct

Adds basic parsing/sema/serialization support for the
#pragma omp target teams loop directive.

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

show more ...

[OpenMP] Initial parsing/sema for the 'omp teams loop' construct

Adds basic parsing/sema/serialization support for the #pragma omp teams loop
directive.

Differential Revision: https://reviews.llvm.

[OpenMP] Initial parsing/sema for the 'omp teams loop' construct

Adds basic parsing/sema/serialization support for the #pragma omp teams loop
directive.

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

show more ...

[Clang] always_inline statement attribute

Motivation:

```
int test(int x, int y) {
int r = 0;
[[clang::always_inline]] r += foo(x, y); // force compiler to inline this function here
re

[Clang] always_inline statement attribute

Motivation:

```
int test(int x, int y) {
int r = 0;
[[clang::always_inline]] r += foo(x, y); // force compiler to inline this function here
return r;
}
```

In 2018, @kuhar proposed "Introduce per-callsite inline intrinsics" in https://reviews.llvm.org/D51200 to solve this motivation case (and many others).

This patch solves this problem with call site attribute. "noinline" statement attribute already landed in D119061. Also, some LLVM Inliner fixes landed so call site attribute is stronger than function attribute.

Reviewed By: aaron.ballman

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

show more ...

[clang][CGStmt] fix crash on invalid asm statement

Clang is crashing on the following statement

char var[9];
__asm__ ("" : "=r" (var) : "0" (var));

This is similar to existing test: crbug_9991

[clang][CGStmt] fix crash on invalid asm statement

Clang is crashing on the following statement

char var[9];
__asm__ ("" : "=r" (var) : "0" (var));

This is similar to existing test: crbug_999160_regtest

The issue happens when EmitAsmStmt is trying to convert input to match
output type length. However, that is not guaranteed to be successful all the
time and if the statement itself is invalid like having an array type in
the example, we should give a regular error message here instead of
using assert().

Reviewed By: MaskRay

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

show more ...

[Clang] noinline call site attribute

Motivation:

```
int foo(int x, int y) { // any compiler will happily inline this function
return x / y;
}

int test(int x, int y) {
int r = 0;
[[cla

[Clang] noinline call site attribute

Motivation:

```
int foo(int x, int y) { // any compiler will happily inline this function
return x / y;
}

int test(int x, int y) {
int r = 0;
[[clang::noinline]] r += foo(x, y); // for some reason we don't want any inlining here
return r;
}

```

In 2018, @kuhar proposed "Introduce per-callsite inline intrinsics" in https://reviews.llvm.org/D51200 to solve this motivation case (and many others).

This patch solves this problem with call site attribute. The implementation is "smaller" wrt approach which uses new intrinsics and thanks to https://reviews.llvm.org/D79121 (Add nomerge statement attribute to clang), we have got some basic infrastructure to deal with attrs on statements with call expressions.

GCC devs are more inclined to call attribute solution as well, as builtins are problematic for them - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187. But they have no patch proposal yet so.. We have free hands here.

If this approach makes sense, next future steps would be support for call site attributes for always_inline / flatten.

Reviewed By: aaron.ballman, kuhar

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

show more ...

[CGBuilder] Remove CreateBitCast() method

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

OMPIRBuilder for Interop directive

Implements the OMPIRBuilder portion for the
Interop directive.

Reviewed By: jdoerfert

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

[clang] number labels in asm goto strings after tied inputs

I noticed that the following case would compile in Clang but not GCC:
void *x(void) {
void *p = &&foo;
asm goto ("# %0\n\t

[clang] number labels in asm goto strings after tied inputs

I noticed that the following case would compile in Clang but not GCC:
void *x(void) {
void *p = &&foo;
asm goto ("# %0\n\t# %l1":"+r"(p):::foo);
foo:;
return p;
}

Changing the output template above from %l2 would compile in GCC but not
Clang.

This demonstrates that when using tied outputs (say via the "+r" output
constraint), the hidden inputs occur or are numbered BEFORE the labels,
at least with GCC.

In fact, GCC does denote this in its documentation:
https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Extended-Asm.html#Goto-Labels

> Output operand with constraint modifier ‘+’ is counted as two operands
> because it is considered as one output and one input operand.

For the sake of compatibility, I think it's worthwhile to just make this
change.

It's better to use symbolic names for compatibility (especially now
between released version of Clang that support asm goto with outputs).
ie. %l1 from the above would be %l[foo]. The GCC docs also make this
recommendation.

Also, I cleaned up some cruft in GCCAsmStmt::getNamedOperand. AFAICT,
NumPlusOperands was no longer used, though I couldn't find which commit
didn't clean that up correctly.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103640
Link: https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Extended-Asm.html#Goto-Labels

Reviewed By: void

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

show more ...

[clang][CGStmt] emit i constraint rather than X for asm goto indirect dests

As suggested in:
https://reviews.llvm.org/D114895#3177794
X will be converted to i by SelectionDAGISEL anyways.

Reviewed

[clang][CGStmt] emit i constraint rather than X for asm goto indirect dests

As suggested in:
https://reviews.llvm.org/D114895#3177794
X will be converted to i by SelectionDAGISEL anyways.

Reviewed By: void, jyknight

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

show more ...

[CodeGen] Emit elementtype attributes for indirect inline asm constraints

This implements the clang side of D116531. The elementtype
attribute is added for all indirect constraints (*) and tests are

[CodeGen] Emit elementtype attributes for indirect inline asm constraints

This implements the clang side of D116531. The elementtype
attribute is added for all indirect constraints (*) and tests are
updated accordingly.

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

show more ...

Avoid setting tbaa on the store of return type of call to inline assembler.

In 32bit mode, attaching TBAA metadata to the store following the call
to inline assembler results in describing the wrong

Avoid setting tbaa on the store of return type of call to inline assembler.

In 32bit mode, attaching TBAA metadata to the store following the call
to inline assembler results in describing the wrong type by making a
fake lvalue(i.e., whatever the inline assembler happens to leave in
EAX:EDX.) Even if inline assembler somehow describes the correct type,
setting TBAA information on return type of call to inline assembler is
likely not correct, since TBAA rules need not apply to inline assembler.

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

show more ...

[clang] Make -masm=intel affect inline asm style

With this,

void f() { __asm__("mov eax, ebx"); }

now compiles with clang with -masm=intel.

This matches gcc.

The flag is not accepted in clang

[clang] Make -masm=intel affect inline asm style

With this,

void f() { __asm__("mov eax, ebx"); }

now compiles with clang with -masm=intel.

This matches gcc.

The flag is not accepted in clang-cl mode. It has no effect on
MSVC-style `__asm {}` blocks, which are unconditionally in intel
mode both before and after this change.

One difference to gcc is that in clang, inline asm strings are
"local" while they're "global" in gcc. Building the following with
-masm=intel works with clang, but not with gcc where the ".att_syntax"
from the 2nd __asm__() is in effect until file end (or until a
".intel_syntax" somewhere later in the file):

__asm__("mov eax, ebx");
__asm__(".att_syntax\nmovl %ebx, %eax");
__asm__("mov eax, ebx");

This also updates clang's intrinsic headers to work both in
-masm=att (the default) and -masm=intel modes.
The official solution for this according to "Multiple assembler dialects in asm
templates" in gcc docs->Extensions->Inline Assembly->Extended Asm
is to write every inline asm snippet twice:

bt{l %[Offset],%[Base] | %[Base],%[Offset]}

This works in LLVM after D113932 and D113894, so use that.

(Just putting `.att_syntax` at the start of the snippet works in some but not
all cases: When LLVM interpolates in parameters like `%0`, it uses at&t or
intel syntax according to the inline asm snippet's flavor, so the `.att_syntax`
within the snippet happens to late: The interpolated-in parameter is already
in intel style, and then won't parse in the switched `.att_syntax`.)

It might be nice to invent a `#pragma clang asm_dialect push "att"` /
`#pragma clang asm_dialect pop` to be able to force asm style per snippet,
so that the inline asm string doesn't contain the same code in two variants,
but let's leave that for a follow-up.

Fixes PR21401 and PR20241.

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

show more ...

[OpenMP] Remove doing assumption propagation in the front end.

This patch removes the assumption propagation that was added in D110655
primarily to get assumption informatino on opaque call sites fo

[OpenMP] Remove doing assumption propagation in the front end.

This patch removes the assumption propagation that was added in D110655
primarily to get assumption informatino on opaque call sites for
optimizations. The analysis done in D111445 allows us to do this more
intelligently in the back-end.

Depends on D111445

Reviewed By: jdoerfert

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

show more ...