[PATCH] D76477: [clang-tidy] Update path of main translation unit

[Jens Carl via Phabricator via cfe-commits]

j-carl created this revision.
Herald added subscribers: cfe-commits, xazax.hun.
Herald added a project: clang.
j-carl added a reviewer: alexfh.
j-carl added a project: clang-tools-extra.
j-carl edited the summary of this revision.
j-carl removed a reviewer: alexfh.
j-carl added a reviewer: alexfh.

The forcing of the linker for a new module was moved from file
clang-tidy/tools/ClangTidyModule.cpp to
clang-tidy/ClangTidyForceLinker.h.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76477

Files:
  clang-tools-extra/docs/clang-tidy/Contributing.rst


Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -256,7 +256,7 @@
 
 And this to the main translation unit of the :program:`clang-tidy` binary (or
 the binary you link the ``clang-tidy`` library in)
-``clang-tidy/tool/ClangTidyMain.cpp``:
+``clang-tidy/ClangTidyForceLinker.h``:
 
 .. code-block:: c++
 


Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -256,7 +256,7 @@
 
 And this to the main translation unit of the :program:`clang-tidy` binary (or
 the binary you link the ``clang-tidy`` library in)
-``clang-tidy/tool/ClangTidyMain.cpp``:
+``clang-tidy/ClangTidyForceLinker.h``:
 
 .. code-block:: c++
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75591: [OpenMP] Add firstprivate as a default data-sharing attribute to clang

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

I'm satisfied with this, @fghanim wdyt?




Comment at: clang/lib/Sema/SemaOpenMP.cpp:5102
   Diag(P.second->getExprLoc(), diag::err_omp_no_dsa_for_variable)
   << P.first << P.second->getSourceRange();
   Diag(DSAStack->getDefaultDSALocation(), diag::note_omp_default_dsa_none);

atmnpatel wrote:
> fghanim wrote:
> > Why is `firstprivate` throwing this error? isn't the purpose of specifying 
> > it as `default` is if a variable is not specified as anything, then it is 
> > automatically handled as `firstprivate`? or am I misunderstanding something?
> My understanding is that if that line isn't there then errors won't be thrown 
> in the special cases where firstprivate explicitly requires a data sharing 
> attribute to be specified - such as for static variable within a 
> namespace/global scope as per the C/C++ restrictions in the technical report.
Do we have a test for that or can we add one, please. (If you remove this and 
an error we expect in the existing tests is not shown anymore that is 
sufficient.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75591/new/

https://reviews.llvm.org/D75591



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75184: [clang-tidy] Optional inheritance of file configs from parent directories

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

In D75184#1914788 , @njames93 wrote:

> In D75184#1914705 , @DmitryPolukhin 
> wrote:
>
> > You are absolutely right about current behaviour. Thank you for catching 
> > this odd behaviour. I'm not 100% confident what is the right behaviour but 
> > my guess is that overriding local option from parent config with global 
> > from child folder is better so I implemented it and added corresponding 
> > test.
>
>
> It's a tricky one that, but I thing overriding the local option with the 
> global in the sub directory is the correct way to go about this as well.


There's one more thing to consider: just by looking at the name of a local 
option we don't know whether it will be read using `get()` or 
`getLocalOrGlobal()`. By removing local options we may introduce an even more 
surprising behavior than without this special treatment. WDYT?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75184/new/

https://reviews.llvm.org/D75184



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D57497: [RISCV] Passing small data limitation value to RISCV backend

[Shiva Chen via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfc3752665f4b: [RISCV] Passing small data limitation value to 
RISCV backend (authored by shiva0217).

Changed prior to commit:
  https://reviews.llvm.org/D57497?vs=250984=251543#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57497/new/

https://reviews.llvm.org/D57497

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/riscv-sdata-module-flag.c
  clang/test/Driver/riscv-sdata-warning.c

Index: clang/test/Driver/riscv-sdata-warning.c
===
--- /dev/null
+++ clang/test/Driver/riscv-sdata-warning.c
@@ -0,0 +1,8 @@
+// REQUIRES: riscv-registered-target
+// RUN: %clang -S -target riscv32-unknown-elf -fpic -msmall-data-limit=8 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-PIC-SDATA %s
+// CHECK-PIC-SDATA: warning: ignoring '-msmall-data-limit=' with -mcmodel=large for -fpic or RV64
+
+// RUN: %clang -S -target riscv64-unknown-elf -mcmodel=large -msmall-data-limit=8 %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-RV64-LARGE-SDATA %s
+// CHECK-RV64-LARGE-SDATA: warning: ignoring '-msmall-data-limit=' with -mcmodel=large for -fpic or RV64
Index: clang/test/CodeGen/riscv-sdata-module-flag.c
===
--- /dev/null
+++ clang/test/CodeGen/riscv-sdata-module-flag.c
@@ -0,0 +1,48 @@
+// RUN: %clang -target riscv32-unknown-elf %s -S -emit-llvm -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32-DEFAULT
+// RUN: %clang -target riscv32-unknown-elf %s -S -emit-llvm -G4 -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32-G4
+// RUN: %clang -target riscv32-unknown-elf %s -S -emit-llvm -msmall-data-limit=0 -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32-S0
+// RUN: %clang -target riscv32-unknown-elf %s -S -emit-llvm -msmall-data-limit=2 -G4 -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32-S2G4
+// RUN: %clang -target riscv32-unknown-elf %s -S -emit-llvm -msmall-data-threshold=16 -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32-T16
+// RUN: %clang -target riscv32-unknown-elf %s -S -emit-llvm -fpic -o - \
+// RUN:   | FileCheck %s -check-prefix=RV32-PIC
+
+// RUN: %clang -target riscv64-unknown-elf %s -S -emit-llvm -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64-DEFAULT
+// RUN: %clang -target riscv64-unknown-elf %s -S -emit-llvm -G4 -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64-G4
+// RUN: %clang -target riscv64-unknown-elf %s -S -emit-llvm -msmall-data-limit=0 -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64-S0
+// RUN: %clang -target riscv64-unknown-elf %s -S -emit-llvm -msmall-data-limit=2 -G4 -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64-S2G4
+// RUN: %clang -target riscv64-unknown-elf %s -S -emit-llvm -msmall-data-threshold=16 -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64-T16
+// RUN: %clang -target riscv64-unknown-elf %s -S -emit-llvm -fpic -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64-PIC
+// RUN: %clang -target riscv64-unknown-elf %s -S -emit-llvm -mcmodel=large -o - \
+// RUN:   | FileCheck %s -check-prefix=RV64-LARGE
+
+void test() {}
+
+// RV32-DEFAULT: !{i32 1, !"SmallDataLimit", i32 8}
+// RV32-G4:  !{i32 1, !"SmallDataLimit", i32 4}
+// RV32-S0:  !{i32 1, !"SmallDataLimit", i32 0}
+// RV32-S2G4:!{i32 1, !"SmallDataLimit", i32 4}
+// RV32-T16: !{i32 1, !"SmallDataLimit", i32 16}
+// RV32-PIC: !{i32 1, !"SmallDataLimit", i32 0}
+
+// RV64-DEFAULT: !{i32 1, !"SmallDataLimit", i32 8}
+// RV64-G4:  !{i32 1, !"SmallDataLimit", i32 4}
+// RV64-S0:  !{i32 1, !"SmallDataLimit", i32 0}
+// RV64-S2G4:!{i32 1, !"SmallDataLimit", i32 4}
+// RV64-T16: !{i32 1, !"SmallDataLimit", i32 16}
+// RV64-PIC: !{i32 1, !"SmallDataLimit", i32 0}
+// RV64-LARGE:   !{i32 1, !"SmallDataLimit", i32 0}
+
+// The value will be passed by module flag instead of target feature.
+// RV32-S0-NOT: +small-data-limit=
+// RV64-S0-NOT: +small-data-limit=
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -921,6 +921,8 @@
   Opts.NoZeroInitializedInBSS = Args.hasArg(OPT_mno_zero_initialized_in_bss);
   Opts.NumRegisterParameters = getLastArgIntValue(Args, OPT_mregparm, 0, Diags);
   Opts.NoExecStack = Args.hasArg(OPT_mno_exec_stack);
+  Opts.SmallDataLimit =
+  getLastArgIntValue(Args, 

[PATCH] D66094: [CodeGen] Emit destructor calls for non-trivial C structs returned by function calls and loaded from volatile objects

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Thank, this looks great.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66094/new/

https://reviews.llvm.org/D66094



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] fc37526 - [RISCV] Passing small data limitation value to RISCV backend

[via cfe-commits]

Author: Shiva Chen
Date: 2020-03-20T11:03:51+08:00
New Revision: fc3752665f4b7ae2ec3faad4204512687800c1ec

URL: 
https://github.com/llvm/llvm-project/commit/fc3752665f4b7ae2ec3faad4204512687800c1ec
DIFF: 
https://github.com/llvm/llvm-project/commit/fc3752665f4b7ae2ec3faad4204512687800c1ec.diff

LOG: [RISCV] Passing small data limitation value to RISCV backend

Passing small data limit to RISCVELFTargetObjectFile by module flag,
So the backend can set small data section threshold by the value.
The data will be put into the small data section if the data smaller than
the threshold.

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

Added: 
clang/test/CodeGen/riscv-sdata-module-flag.c
clang/test/Driver/riscv-sdata-warning.c

Modified: 
clang/docs/ClangCommandLineReference.rst
clang/include/clang/Basic/CodeGenOptions.def
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Driver/CC1Options.td
clang/include/clang/Driver/Options.td
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/CodeGen/CodeGenModule.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/CompilerInvocation.cpp

Removed: 




diff  --git a/clang/docs/ClangCommandLineReference.rst 
b/clang/docs/ClangCommandLineReference.rst
index 74e831c36eb9..3f0e471e852a 100644
--- a/clang/docs/ClangCommandLineReference.rst
+++ b/clang/docs/ClangCommandLineReference.rst
@@ -2403,7 +2403,7 @@ Target-dependent compilation options
 
 .. option:: -G, -G=, -msmall-data-threshold=
 
-Put objects of at most  bytes into small data section (MIPS / Hexagon)
+Put objects of at most  bytes into small data section (MIPS / Hexagon / 
RISCV)
 
 .. option:: -ffixed-x1
 
@@ -3201,6 +3201,10 @@ Enable linker relaxation
 
 Enable using library calls for save and restore
 
+.. option:: -msmall-data-limit=
+
+Put global and static data smaller than the limit into a special section
+
 Long double flags
 -
 Selects the long double implementation

diff  --git a/clang/include/clang/Basic/CodeGenOptions.def 
b/clang/include/clang/Basic/CodeGenOptions.def
index e047054447f3..5b59954fae7b 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -306,6 +306,9 @@ CODEGENOPT(LTOVisibilityPublicStd, 1, 0)
 /// or 0 if unspecified.
 VALUE_CODEGENOPT(NumRegisterParameters, 32, 0)
 
+/// The threshold to put data into small data section.
+VALUE_CODEGENOPT(SmallDataLimit, 32, 0)
+
 /// The lower bound for a buffer to be considered for stack protection.
 VALUE_CODEGENOPT(SSPBufferSize, 32, 0)
 

diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 48ece91d3c45..2d13295bd301 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -399,6 +399,9 @@ def warn_drv_unsupported_gpopt : Warning<
   "ignoring '-mgpopt' option as it cannot be used with %select{|the implicit"
   " usage of }0-mabicalls">,
   InGroup;
+def warn_drv_unsupported_sdata : Warning<
+  "ignoring '-msmall-data-limit=' with -mcmodel=large for -fpic or RV64">,
+  InGroup;
 def warn_drv_unsupported_longcalls : Warning<
   "ignoring '-mlong-calls' option as it is not currently supported with "
   "%select{|the implicit usage of }0-mabicalls">,

diff  --git a/clang/include/clang/Driver/CC1Options.td 
b/clang/include/clang/Driver/CC1Options.td
index cc30893703df..66a443b0d0f4 100644
--- a/clang/include/clang/Driver/CC1Options.td
+++ b/clang/include/clang/Driver/CC1Options.td
@@ -313,6 +313,8 @@ def mno_zero_initialized_in_bss : Flag<["-"], 
"mno-zero-initialized-in-bss">,
   HelpText<"Do not put zero initialized data in the BSS">;
 def mregparm : Separate<["-"], "mregparm">,
   HelpText<"Limit the number of registers available for integer arguments">;
+def msmall_data_limit : Separate<["-"], "msmall-data-limit">,
+  HelpText<"Put global and static data smaller than the limit into a special 
section">;
 def munwind_tables : Flag<["-"], "munwind-tables">,
   HelpText<"Generate unwinding tables for all functions">;
 def mconstructor_aliases : Flag<["-"], "mconstructor-aliases">,

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 3a4830c84483..19bb72c55aa8 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2300,6 +2300,9 @@ def mrelax : Flag<["-"], "mrelax">, 
Group,
   HelpText<"Enable linker relaxation">;
 def mno_relax : Flag<["-"], "mno-relax">, Group,
   HelpText<"Disable linker relaxation">;
+def msmall_data_limit_EQ : Joined<["-"], "msmall-data-limit=">, Group,
+  Alias,
+  HelpText<"Put global and static data smaller than the limit into a special 
section">;
 def msave_restore : Flag<["-"], "msave-restore">, 
Group,
   HelpText<"Enable using 

[PATCH] D60748: Adds an option "malign-pass-aggregate" to make the alignment of the struct and union parameters compatible with the default gcc

[LiuChen via Phabricator via cfe-commits]

LiuChen3 added a comment.

> I think at least the initial patch is correct.

I re-read your comment above, please ignore this sentence. Sorry for the noise.
My question now is that since we cannot guarantee that we are doing the right 
thing, is this patch necessary?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60748/new/

https://reviews.llvm.org/D60748



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76416: [WIP][ASan] Apply -ffile-prefix-map mappings to ASan instrumentation

[Leonard Chan via Phabricator via cfe-commits]

leonardchan added a subscriber: mcgrathr.
leonardchan added a comment.

Putting this on hold for now. Although this implementation works for ASan, it 
would be have to be repeated for other tools like SourceBasedCoverage or other 
sanitizers.

After discussing with @phosek and @mcgrathr, a more general approach would be 
to develop some internal API that allows users to get SourceLocations for 
metadata or other paths that will be embeded in IR. Then once we have a single 
source for retrieving these paths, we could apply `-ffile-prefix-mapping`s once 
to prevent having to propagate the mapping down to IR.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76416/new/

https://reviews.llvm.org/D76416



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60748: Adds an option "malign-pass-aggregate" to make the alignment of the struct and union parameters compatible with the default gcc

[LiuChen via Phabricator via cfe-commits]

LiuChen3 marked 3 inline comments as done.
LiuChen3 added a comment.

In D60748#1931440 , @jyknight wrote:

> Since the ABI this is trying to match is not documented literally anywhere, I 
> think we need to have some confidence that what this implements is actually 
> the same as what GCC does. While I wrote up what I think the algorithm is, 
> without some sort of script to allow testing it against a bunch of examples, 
> I wouldn't say I'm confident of its correctness.
>
> I'm not sure if you can reverse-engineer what the alignment must have been 
> from the assembly output, or from some debug flags. Or if maybe doing 
> something silly like modifying the source to insert a printf would be the 
> best method to test this.


I think at least the initial patch is correct.




Comment at: clang/include/clang/Basic/LangOptions.def:353
 
+VALUE_LANGOPT(AlignPassingAggregate, 1, 0, "Compatible with gcc default 
passing struct and union (x86 only).")
+

rnk wrote:
> If only codegen needs to know, a CodeGenOption would be better.
The backend does not need this option information.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:1556
+
+  for (RecordDecl::field_iterator i = RD->field_begin(), e = 
RD->field_end();
+   i != e; ++i) {

rnk wrote:
> Any time you crack open a record to look at the fields, the code is probably 
> wrong the first time you write it. :( In this case, I suspect you are not 
> looking at base classes. Consider:
> ```
> struct A {
>   MyAlignedType Field;
> };
> struct B : A {};
> void passbyval(B o);
> ```
I'm not sure if I understand what you mean.



```
typedef __attribute__((aligned(16))) int alignedint16;
typedef __attribute__((aligned(64))) int alignedint64;
struct __attribute__((aligned(64))) X2 {
  struct  __attribute__((aligned(32))) {
int a1;
alignedint16 a2;
  } a;
  int b;
};
struct B : X2{};
void test(B b)
{
  std::cout << b.a.a2 << std::endl;
}
```
This can pass.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:1542-1544
+// i386 System V ABI 2.1: Structures and unions assume the alignment of 
their
+// most strictly aligned component.
+//

jyknight wrote:
> This comment isn't useful. While it may be what the System V ABI document 
> says, that's clearly incorreect, and is  not what the code is or should be 
> doing. Please document what is actually implemented, instead.
Sorry I forget to change it.



Comment at: clang/test/CodeGen/x86_32-align-linux.cpp:9
+
+class __attribute__((aligned(64))) X1 {
+  class  __attribute__((aligned(32))) {

jyknight wrote:
> Confused me that this was a different X1 than in the test-case above. I'm not 
> sure why the tests need to be duplicated here in a .cpp file in the first 
> place?
Sorry that I don't know much about front-end tests. I thought class, struct and 
union all need to be tested.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60748/new/

https://reviews.llvm.org/D60748



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76472: AMDGPU: Emit llvm.fshr for __builtin_amdgcn_alignbit

[Matt Arsenault via Phabricator via cfe-commits]

arsenm created this revision.
arsenm added reviewers: yaxunl, rampitec.
Herald added subscribers: kerbowa, t-tye, tpr, dstuttard, nhaehnle, wdng, 
jvesely, kzhuravl.

These are equivalent. The generic rotate builtins do not directly map
to the fshr intrinsic.


https://reviews.llvm.org/D76472

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGenOpenCL/builtins-amdgcn.cl
  llvm/include/llvm/IR/IntrinsicsAMDGPU.td


Index: llvm/include/llvm/IR/IntrinsicsAMDGPU.td
===
--- llvm/include/llvm/IR/IntrinsicsAMDGPU.td
+++ llvm/include/llvm/IR/IntrinsicsAMDGPU.td
@@ -1371,8 +1371,8 @@
   [IntrNoMem, IntrConvergent]
 >;
 
-def int_amdgcn_alignbit :
-  GCCBuiltin<"__builtin_amdgcn_alignbit">, Intrinsic<[llvm_i32_ty],
+// FIXME: Deprecated. This is equivalent to llvm.fshr
+def int_amdgcn_alignbit : Intrinsic<[llvm_i32_ty],
   [llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
   [IntrNoMem, IntrSpeculatable]
 >;
Index: clang/test/CodeGenOpenCL/builtins-amdgcn.cl
===
--- clang/test/CodeGenOpenCL/builtins-amdgcn.cl
+++ clang/test/CodeGenOpenCL/builtins-amdgcn.cl
@@ -596,7 +596,7 @@
 }
 
 // CHECK-LABEL: @test_alignbit(
-// CHECK: tail call i32 @llvm.amdgcn.alignbit(i32 %src0, i32 %src1, i32 %src2)
+// CHECK: tail call i32 @llvm.fshr.i32(i32 %src0, i32 %src1, i32 %src2)
 kernel void test_alignbit(global uint* out, uint src0, uint src1, uint src2) {
   *out = __builtin_amdgcn_alignbit(src0, src1, src2);
 }
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -13609,6 +13609,13 @@
 return emitRangedBuiltin(*this, Intrinsic::r600_read_tidig_y, 0, 1024);
   case AMDGPU::BI__builtin_r600_read_tidig_z:
 return emitRangedBuiltin(*this, Intrinsic::r600_read_tidig_z, 0, 1024);
+  case AMDGPU::BI__builtin_amdgcn_alignbit: {
+llvm::Value *Src0 = EmitScalarExpr(E->getArg(0));
+llvm::Value *Src1 = EmitScalarExpr(E->getArg(1));
+llvm::Value *Src2 = EmitScalarExpr(E->getArg(2));
+Function *F = CGM.getIntrinsic(Intrinsic::fshr, Src0->getType());
+return Builder.CreateCall(F, { Src0, Src1, Src2 });
+  }
   default:
 return nullptr;
   }


Index: llvm/include/llvm/IR/IntrinsicsAMDGPU.td
===
--- llvm/include/llvm/IR/IntrinsicsAMDGPU.td
+++ llvm/include/llvm/IR/IntrinsicsAMDGPU.td
@@ -1371,8 +1371,8 @@
   [IntrNoMem, IntrConvergent]
 >;
 
-def int_amdgcn_alignbit :
-  GCCBuiltin<"__builtin_amdgcn_alignbit">, Intrinsic<[llvm_i32_ty],
+// FIXME: Deprecated. This is equivalent to llvm.fshr
+def int_amdgcn_alignbit : Intrinsic<[llvm_i32_ty],
   [llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
   [IntrNoMem, IntrSpeculatable]
 >;
Index: clang/test/CodeGenOpenCL/builtins-amdgcn.cl
===
--- clang/test/CodeGenOpenCL/builtins-amdgcn.cl
+++ clang/test/CodeGenOpenCL/builtins-amdgcn.cl
@@ -596,7 +596,7 @@
 }
 
 // CHECK-LABEL: @test_alignbit(
-// CHECK: tail call i32 @llvm.amdgcn.alignbit(i32 %src0, i32 %src1, i32 %src2)
+// CHECK: tail call i32 @llvm.fshr.i32(i32 %src0, i32 %src1, i32 %src2)
 kernel void test_alignbit(global uint* out, uint src0, uint src1, uint src2) {
   *out = __builtin_amdgcn_alignbit(src0, src1, src2);
 }
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -13609,6 +13609,13 @@
 return emitRangedBuiltin(*this, Intrinsic::r600_read_tidig_y, 0, 1024);
   case AMDGPU::BI__builtin_r600_read_tidig_z:
 return emitRangedBuiltin(*this, Intrinsic::r600_read_tidig_z, 0, 1024);
+  case AMDGPU::BI__builtin_amdgcn_alignbit: {
+llvm::Value *Src0 = EmitScalarExpr(E->getArg(0));
+llvm::Value *Src1 = EmitScalarExpr(E->getArg(1));
+llvm::Value *Src2 = EmitScalarExpr(E->getArg(2));
+Function *F = CGM.getIntrinsic(Intrinsic::fshr, Src0->getType());
+return Builder.CreateCall(F, { Src0, Src1, Src2 });
+  }
   default:
 return nullptr;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76397: [WebAssembly] SIMD bitmask intrinsics and builtin functions

[Thomas Lively via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa3f974f3c332: [WebAssembly] SIMD bitmask intrinsics and 
builtin functions (authored by tlively).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76397/new/

https://reviews.llvm.org/D76397

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
  llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
  llvm/test/MC/WebAssembly/simd-encodings.s

Index: llvm/test/MC/WebAssembly/simd-encodings.s
===
--- llvm/test/MC/WebAssembly/simd-encodings.s
+++ llvm/test/MC/WebAssembly/simd-encodings.s
@@ -580,4 +580,13 @@
 # CHECK: i32x4.dot_i16x8_s # encoding: [0xfd,0xdb,0x01]
 i32x4.dot_i16x8_s
 
+# CHECK: i8x16.bitmask # encoding: [0xfd,0xe4,0x01]
+i8x16.bitmask
+
+# CHECK: i16x8.bitmask # encoding: [0xfd,0xe5,0x01]
+i16x8.bitmask
+
+# CHECK: i32x4.bitmask # encoding: [0xfd,0xe6,0x01]
+i32x4.bitmask
+
 end_function
Index: llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
+++ llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
@@ -95,6 +95,16 @@
   ret i32 %a
 }
 
+; CHECK-LABEL: bitmask_v16i8:
+; SIMD128-NEXT: .functype bitmask_v16i8 (v128) -> (i32){{$}}
+; SIMD128-NEXT: i8x16.bitmask $push[[R:[0-9]+]]=, $0{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare i32 @llvm.wasm.bitmask.v16i8(<16 x i8>)
+define i32 @bitmask_v16i8(<16 x i8> %x) {
+  %a = call i32 @llvm.wasm.bitmask.v16i8(<16 x i8> %x)
+  ret i32 %a
+}
+
 ; CHECK-LABEL: bitselect_v16i8:
 ; SIMD128-NEXT: .functype bitselect_v16i8 (v128, v128, v128) -> (v128){{$}}
 ; SIMD128-NEXT: v128.bitselect $push[[R:[0-9]+]]=, $0, $1, $2{{$}}
@@ -208,6 +218,16 @@
   ret i32 %a
 }
 
+; CHECK-LABEL: bitmask_v8i16:
+; SIMD128-NEXT: .functype bitmask_v8i16 (v128) -> (i32){{$}}
+; SIMD128-NEXT: i16x8.bitmask $push[[R:[0-9]+]]=, $0{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare i32 @llvm.wasm.bitmask.v8i16(<8 x i16>)
+define i32 @bitmask_v8i16(<8 x i16> %x) {
+  %a = call i32 @llvm.wasm.bitmask.v8i16(<8 x i16> %x)
+  ret i32 %a
+}
+
 ; CHECK-LABEL: bitselect_v8i16:
 ; SIMD128-NEXT: .functype bitselect_v8i16 (v128, v128, v128) -> (v128){{$}}
 ; SIMD128-NEXT: v128.bitselect $push[[R:[0-9]+]]=, $0, $1, $2{{$}}
@@ -317,6 +337,16 @@
   ret i32 %a
 }
 
+; CHECK-LABEL: bitmask_v4i32:
+; SIMD128-NEXT: .functype bitmask_v4i32 (v128) -> (i32){{$}}
+; SIMD128-NEXT: i32x4.bitmask $push[[R:[0-9]+]]=, $0{{$}}
+; SIMD128-NEXT: return $pop[[R]]{{$}}
+declare i32 @llvm.wasm.bitmask.v4i32(<4 x i32>)
+define i32 @bitmask_v4i32(<4 x i32> %x) {
+  %a = call i32 @llvm.wasm.bitmask.v4i32(<4 x i32> %x)
+  ret i32 %a
+}
+
 ; CHECK-LABEL: bitselect_v4i32:
 ; SIMD128-NEXT: .functype bitselect_v4i32 (v128, v128, v128) -> (v128){{$}}
 ; SIMD128-NEXT: v128.bitselect $push[[R:[0-9]+]]=, $0, $1, $2{{$}}
Index: llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
===
--- llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
+++ llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
@@ -606,6 +606,18 @@
   (i32 (!cast(reduction[1]#"_"#ty) (ty V128:$x)))>;
 }
 
+multiclass SIMDBitmask simdop> {
+  defm _#vec_t : SIMD_I<(outs I32:$dst), (ins V128:$vec), (outs), (ins),
+ [(set I32:$dst,
+   (i32 (int_wasm_bitmask (vec_t V128:$vec)))
+ )],
+ vec#".bitmask\t$dst, $vec", vec#".bitmask", simdop>;
+}
+
+defm BITMASK : SIMDBitmask;
+defm BITMASK : SIMDBitmask;
+defm BITMASK : SIMDBitmask;
+
 //===--===//
 // Bit shifts
 //===--===//
Index: llvm/include/llvm/IR/IntrinsicsWebAssembly.td
===
--- llvm/include/llvm/IR/IntrinsicsWebAssembly.td
+++ llvm/include/llvm/IR/IntrinsicsWebAssembly.td
@@ -129,6 +129,10 @@
   Intrinsic<[llvm_i32_ty],
 [llvm_anyvector_ty],
 [IntrNoMem, IntrSpeculatable]>;
+def int_wasm_bitmask :
+  Intrinsic<[llvm_i32_ty],
+[llvm_anyvector_ty],
+[IntrNoMem, IntrSpeculatable]>;
 def int_wasm_qfma :
   Intrinsic<[llvm_anyvector_ty],
 [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>],
Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -511,6 +511,24 @@
   // WEBASSEMBLY: ret
 }
 
+int bitmask_i8x16(i8x16 x) {
+  return 

[PATCH] D75685: Add MS Mangling for OpenCL Pipe types, add mangling test.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Ping! I would expect this to be non-controversial, but if there is a different 
reviewer anyone can suggest, I'd appreciate it!

Thanks!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75685/new/

https://reviews.llvm.org/D75685



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76365: [cuda][hip] Add CUDA builtin surface/texture reference support.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D76365#1932439 , @hliao wrote:

>




> That's a magic. I could not figure out how it works. From its use, e.g. 
> `tex2D` on `texture`,
> 
>   __nv_tex_surf_handler("__tex2D_v2", (typename __nv_tex_rmet_cast::type) 
> , t, x, y);
> 
> 
> `__tex2D_v2` is a string literal. However, it's more likely a underly 
> function name for the real implementation. Hardly imagine that that string 
> literal is checked directly instead used for constructing the real function 
> name. If that's the case, we also need to find that where that underlying 
> functions are defined as the device bitcode library has no such definition.

Most likely it's a compiler built-in with no implementation we could reuse and 
we'll need to implement our own. It should be fairly straightforward to figure 
out what it does by compiling all variants used by CUDA headers and observing 
generated PTX. The first 'meta' argument may be tricky, but we should be able 
to retrieve the constant string value in the front-end and map it to 
appropriate intrinsic or generate necessary glue.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76365/new/

https://reviews.llvm.org/D76365



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] a3f974f - [WebAssembly] SIMD bitmask intrinsics and builtin functions

[Thomas Lively via cfe-commits]

Author: Thomas Lively
Date: 2020-03-19T17:15:37-07:00
New Revision: a3f974f3c3321d602a49f8ada3d3d4dd34db792a

URL: 
https://github.com/llvm/llvm-project/commit/a3f974f3c3321d602a49f8ada3d3d4dd34db792a
DIFF: 
https://github.com/llvm/llvm-project/commit/a3f974f3c3321d602a49f8ada3d3d4dd34db792a.diff

LOG: [WebAssembly] SIMD bitmask intrinsics and builtin functions

Summary:
These experimental new instructions are proposed in
https://github.com/WebAssembly/simd/pull/201.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsWebAssembly.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/builtins-wasm.c
llvm/include/llvm/IR/IntrinsicsWebAssembly.td
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
llvm/test/MC/WebAssembly/simd-encodings.s

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsWebAssembly.def 
b/clang/include/clang/Basic/BuiltinsWebAssembly.def
index b544e3b42137..86d17fc952ec 100644
--- a/clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ b/clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -125,6 +125,10 @@ TARGET_BUILTIN(__builtin_wasm_all_true_i16x8, "iV8s", 
"nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_all_true_i32x4, "iV4i", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_all_true_i64x2, "iV2LLi", "nc", 
"unimplemented-simd128")
 
+TARGET_BUILTIN(__builtin_wasm_bitmask_i8x16, "iV16c", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_bitmask_i16x8, "iV8s", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_bitmask_i32x4, "iV4i", "nc", "simd128")
+
 TARGET_BUILTIN(__builtin_wasm_abs_f32x4, "V4fV4f", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_abs_f64x2, "V2dV2d", "nc", "simd128")
 

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index e42339dbcfcc..413dbf95f1b9 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -15142,6 +15142,14 @@ Value 
*CodeGenFunction::EmitWebAssemblyBuiltinExpr(unsigned BuiltinID,
 Function *Callee = CGM.getIntrinsic(IntNo, Vec->getType());
 return Builder.CreateCall(Callee, {Vec});
   }
+  case WebAssembly::BI__builtin_wasm_bitmask_i8x16:
+  case WebAssembly::BI__builtin_wasm_bitmask_i16x8:
+  case WebAssembly::BI__builtin_wasm_bitmask_i32x4: {
+Value *Vec = EmitScalarExpr(E->getArg(0));
+Function *Callee =
+CGM.getIntrinsic(Intrinsic::wasm_bitmask, Vec->getType());
+return Builder.CreateCall(Callee, {Vec});
+  }
   case WebAssembly::BI__builtin_wasm_abs_f32x4:
   case WebAssembly::BI__builtin_wasm_abs_f64x2: {
 Value *Vec = EmitScalarExpr(E->getArg(0));

diff  --git a/clang/test/CodeGen/builtins-wasm.c 
b/clang/test/CodeGen/builtins-wasm.c
index b27bf75248ca..0d70ea601d79 100644
--- a/clang/test/CodeGen/builtins-wasm.c
+++ b/clang/test/CodeGen/builtins-wasm.c
@@ -511,6 +511,24 @@ int all_true_i64x2(i64x2 x) {
   // WEBASSEMBLY: ret
 }
 
+int bitmask_i8x16(i8x16 x) {
+  return __builtin_wasm_bitmask_i8x16(x);
+  // WEBASSEMBLY: call i32 @llvm.wasm.bitmask.v16i8(<16 x i8> %x)
+  // WEBASSEMBLY: ret
+}
+
+int bitmask_i16x8(i16x8 x) {
+  return __builtin_wasm_bitmask_i16x8(x);
+  // WEBASSEMBLY: call i32 @llvm.wasm.bitmask.v8i16(<8 x i16> %x)
+  // WEBASSEMBLY: ret
+}
+
+int bitmask_i32x4(i32x4 x) {
+  return __builtin_wasm_bitmask_i32x4(x);
+  // WEBASSEMBLY: call i32 @llvm.wasm.bitmask.v4i32(<4 x i32> %x)
+  // WEBASSEMBLY: ret
+}
+
 f32x4 abs_f32x4(f32x4 x) {
   return __builtin_wasm_abs_f32x4(x);
   // WEBASSEMBLY: call <4 x float> @llvm.fabs.v4f32(<4 x float> %x)

diff  --git a/llvm/include/llvm/IR/IntrinsicsWebAssembly.td 
b/llvm/include/llvm/IR/IntrinsicsWebAssembly.td
index e97700ad724a..90b5a25d16c0 100644
--- a/llvm/include/llvm/IR/IntrinsicsWebAssembly.td
+++ b/llvm/include/llvm/IR/IntrinsicsWebAssembly.td
@@ -129,6 +129,10 @@ def int_wasm_alltrue :
   Intrinsic<[llvm_i32_ty],
 [llvm_anyvector_ty],
 [IntrNoMem, IntrSpeculatable]>;
+def int_wasm_bitmask :
+  Intrinsic<[llvm_i32_ty],
+[llvm_anyvector_ty],
+[IntrNoMem, IntrSpeculatable]>;
 def int_wasm_qfma :
   Intrinsic<[llvm_anyvector_ty],
 [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>],

diff  --git a/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td 
b/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
index 144b7f6ca23e..7743a284091e 100644
--- a/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
+++ b/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
@@ -606,6 +606,18 @@ def : Pat<(i32 (seteq
   (i32 (!cast(reduction[1]#"_"#ty) (ty V128:$x)))>;
 }
 
+multiclass SIMDBitmask simdop> {
+  defm _#vec_t : SIMD_I<(outs I32:$dst), (ins V128:$vec), (outs), (ins),
+  

[PATCH] D76438: ConstantExpr cached APValues if present for constant evaluation

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:7329
+  if (Result.isLValue())
+return Success(Result, E);
+}

wchilders wrote:
> rsmith wrote:
> > wchilders wrote:
> > > This doesn't seem to be the right answer, and `ConstantExpr`s don't have 
> > > `LValue` `APValue`s, at least, not that are reaching this case. We had a 
> > > previous implementation that also, kind of punted on this issue with an 
> > > override in `TemporaryExprEvaluator`: 
> > > https://gitlab.com/lock3/clang/-/blob/9fbaeea06fc567ac472264bec2a72661a1e06c73/clang/lib/AST/ExprConstant.cpp#L9753
> > The base class version seems appropriate to me, even for this case. We 
> > eventually want to use `ConstantExpr` to store the evaluated initializer 
> > value of a `constexpr` variable (replacing the existing special-case 
> > caching on `VarDecl`) and the like, not only for immediate invocations, and 
> > once we start doing that for reference variables we'll have glvalue 
> > `ConstantExpr`s.
> > 
> > Is there some circumstance under which a glvalue `ConstantExpr`'s `APValue` 
> > result is not of kind `LValue`?
> > Is there some circumstance under which a glvalue ConstantExpr's APValue 
> > result is not of kind LValue?
> 
> Good question, the `Sema/switch.c` test fails if you 
> `assert(Result.isLValue())`.
> 
> ```
> ConstantExpr 0x62ab8760 'const int' lvalue Int: 3
> `-DeclRefExpr 0x62ab8740 'const int' lvalue Var 0x62ab8230 'a' 'const 
> int'
> ```
> 
> With an attributed line no. 359: 
> https://github.com/llvm/llvm-project/blob/4b0029995853fe37d1dc95ef96f46697c743fcad/clang/test/Sema/switch.c#L359
> 
> The offending RValue is created in SemaExpr.cpp here: 
> https://github.com/llvm/llvm-project/blob/f87563661d6661fd4843beb8f391acd077b08dbe/clang/lib/Sema/SemaExpr.cpp#L15190
> 
> The issue stems from evaluating this as an RValue to produce an integer, then 
> caching that RValue in an lvalue constant expression. Do you have any 
> suggestions? Perhaps an LValue to RValue conversion should be performed on 
> the expression if it folds correctly, so that the ConstantExpr is actually an 
> RValue?
I think we should be inserting the lvalue-to-rvalue conversion before we even 
try evaluating the expression. Does this go wrong along both the C++11 and 
pre-C++11 codepaths? (They do rather different conversions to the expression.) 
In any case, we're likely missing a call to `DefaultLvalueConversion` on 
whichever side is failing.

Judging by the fact that `struct X { void f() { switch (0) case f: ; } };` 
misses the "non-static member function must be called" diagnostic only in C++98 
mode, I'd imagine it's just the pre-C++11 codepath that's broken here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76438/new/

https://reviews.llvm.org/D76438



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76365: [cuda][hip] Add CUDA builtin surface/texture reference support.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D76365#1932398 , @tra wrote:

> I believe LLVM does have `nvvm.texsurf.handle` implemented: 
> https://github.com/llvm/llvm-project/blob/d9972f848294b06807c8764615852ba2bc1e8a74/llvm/include/llvm/IR/IntrinsicsNVVM.td#L1150


This one only adds the definition but NVPTX backend doesn't handle it.

> We also appear to have some plumbing for it in clang: 
> https://github.com/llvm/llvm-project/blob/31262d6722c7ae6a9966a76064af43e5b3a8df71/llvm/lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp#L724

Yeah, that's so far the `internal` version is used. The original one with one 
metadata as parameter that's only used to prevent CSE as the handle loading 
should be not optimized away or difficult for the backend to handle it. We 
should be able to add that intrinsic support easily. I could add that later. 
That should not be a big issue.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76365/new/

https://reviews.llvm.org/D76365



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76447: Apply ConstantEvaluated evaluation contexts to more manifestly constant evaluated scopes

[Wyatt Childers via Phabricator via cfe-commits]

wchilders added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:16793-16797
+  if (isManifestlyEvaluatedVar(*this, D)) {
+using ExpressionKind = ExpressionEvaluationContextRecord::ExpressionKind;
+
+PushExpressionEvaluationContext(
+ExpressionEvaluationContext::ConstantEvaluated, D, 
ExpressionKind::EK_ConstexprVarInit);

rsmith wrote:
> We can't implement the checks for manifestly constant-evaluated initializers 
> this way in general. Per [expr.const]/14, we need to treat the initializer as 
> manifestly constant-evaluated if it's "the initializer of a variable that is 
> usable in constant expressions or has constant initialization". We can't test 
> either of those conditions in general until we know what the initializer is, 
> because they can both depend on whether evaluation of the initializer 
> succeeds. (This approach works for the case of `constexpr` variables, which 
> are always usable in constant expressions, but not any of the other cases, 
> and the approach we'll need for the other cases will also handle `constexpr` 
> variables. There is a very modest benefit to special-casing `constexpr` 
> variable initializers regardless -- we can avoid forming and then pruning out 
> nested `ConstantExpr` nodes for immediate invocations inside the initializer 
> -- but I think it's probably not worth the added complexity.)
> 
> To address the general problem, we should handle this in 
> `CheckCompleteVariableDeclaration`, which is where we evaluate the 
> initializer and generally determine whether the variable has constant 
> initialization and / or is usable in constant expressions. Probably the 
> cleanest approach -- and certainly the one I'd been intending to pursue -- 
> would be to wrap the initializer with a `ConstantExpr` there in the relevant 
> cases, and allow the usual handling of nested immediate invocations to prune 
> out any `ConstantExpr`s nested within the initializer representing inner 
> calls to `consteval` functions. (I think I've mentioned elsewhere that I 
> would like to remove the "evaluated value" storage on `VarDecl` in favor of 
> using `ConstantExpr` for this purpose.)
> There is a very modest benefit to special-casing constexpr variable 
> initializers regardless -- we can avoid forming and then pruning out nested 
> ConstantExpr nodes for immediate invocations inside the initializer -- but I 
> think it's probably not worth the added complexity.

So, this patch is motivated for us by the desire to check if a "meta type" 
variable, belongs to a compile time, or runtime. Additionally, this is used 
being used to verify our compile time, "injection statement", is not appearing 
in a runtime context. This prevents reflections/metaprogramming values and 
logic from leaking nonsensically into runtime code. 

I think this can be accomplished as you said in the 
`CheckCompleteVariableDeclaration`. We're already checking for out of place 
"meta type" variables there, though we catch fragments, and injection 
statements more eagerly. In retrospect, I don't think there is any issue 
removing the eager check from the fragments, and I don't think the checking of 
the injection statements should be affected by this case.

I'll try and look more into this in the morning.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76447/new/

https://reviews.llvm.org/D76447



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76365: [cuda][hip] Add CUDA builtin surface/texture reference support.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D76365#1932392 , @tra wrote:

> > Note that, clang-based one needs defining texture fetch functions as they 
> > could not be reused from CUDA SDK. That part is enclosed with #if 
> > defined(__clang__).
>
> What prevents clang to compile the texture functions in the CUDA headers? It 
> looks like we'll need to implement the `__nv_tex_surf_handler()` builtin, but 
> other than that it should work.


That's a magic. I could not figure out how it works. From its use, e.g. `tex2D` 
on `texture`,

  __nv_tex_surf_handler("__tex2D_v2", (typename __nv_tex_rmet_cast::type) 
, t, x, y);

`__tex2D_v2` is a string literal. However, it's more likely a underly function 
name for the real implementation. Hardly imagine that that string literal is 
checked directly instead used for constructing the real function name. If 
that's the case, we also need to find that where that underlying functions are 
defined as the device bitcode library has no such definition.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76365/new/

https://reviews.llvm.org/D76365



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76452: Use LLD by default for Android.

[Dan Albert via Phabricator via cfe-commits]

danalbert updated this revision to Diff 251498.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76452/new/

https://reviews.llvm.org/D76452

Files:
  clang/lib/Driver/ToolChains/Linux.h
  clang/test/Driver/Inputs/basic_android_tree/arm-linux-androideabi/bin/ld.lld
  clang/test/Driver/Inputs/basic_android_tree/bin/ld.lld
  clang/test/Driver/coverage-ld.c
  clang/test/Driver/fuse-ld.c
  clang/test/Driver/sanitizer-ld.c

Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -146,7 +146,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID %s
 //
-// CHECK-ASAN-ANDROID: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-ASAN-ANDROID: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-ASAN-ANDROID-NOT: "-lc"
 // CHECK-ASAN-ANDROID-NOT: "-pie"
 // CHECK-ASAN-ANDROID-NOT: "-lpthread"
@@ -159,7 +159,7 @@
 // RUN: -static-libsan \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID-STATICLIBASAN %s
 //
-// CHECK-ASAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-ASAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-ASAN-ANDROID-STATICLIBASAN: libclang_rt.asan-arm-android.a"
 // CHECK-ASAN-ANDROID-STATICLIBASAN-NOT: "-lpthread"
 // CHECK-ASAN-ANDROID-STATICLIBASAN-NOT: "-lrt"
@@ -169,7 +169,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-ANDROID %s
 //
-// CHECK-UBSAN-ANDROID: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-UBSAN-ANDROID: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-UBSAN-ANDROID-NOT: "-lc"
 // CHECK-UBSAN-ANDROID-NOT: "-pie"
 // CHECK-UBSAN-ANDROID-NOT: "-lpthread"
@@ -182,7 +182,7 @@
 // RUN: -static-libsan \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-ANDROID-STATICLIBASAN %s
 //
-// CHECK-UBSAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-UBSAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-UBSAN-ANDROID-STATICLIBASAN: libclang_rt.ubsan_standalone-arm-android.a"
 // CHECK-UBSAN-ANDROID-STATICLIBASAN-NOT: "-lpthread"
 // CHECK-UBSAN-ANDROID-STATICLIBASAN-NOT: "-lrt"
@@ -193,7 +193,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID-X86 %s
 //
-// CHECK-ASAN-ANDROID-X86: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-ASAN-ANDROID-X86: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-ASAN-ANDROID-X86-NOT: "-lc"
 // CHECK-ASAN-ANDROID-X86-NOT: "-pie"
 // CHECK-ASAN-ANDROID-X86-NOT: "-lpthread"
@@ -214,7 +214,7 @@
 // RUN: -shared \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID-SHARED %s
 //
-// CHECK-ASAN-ANDROID-SHARED: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-ASAN-ANDROID-SHARED: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-ASAN-ANDROID-SHARED-NOT: "-lc"
 // CHECK-ASAN-ANDROID-SHARED: libclang_rt.asan-arm-android.so"
 // CHECK-ASAN-ANDROID-SHARED-NOT: "-lpthread"
@@ -560,7 +560,7 @@
 // RUN: -target aarch64-linux-android -fuse-ld=ld \
 // RUN: --sysroot=%S/Inputs/basic_android_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-CFI-CROSS-DSO-ANDROID %s
-// CHECK-CFI-CROSS-DSO-ANDROID: "{{.*}}ld{{(.exe)?}}"
+// CHECK-CFI-CROSS-DSO-ANDROID: "{{.*}}ld.lld{{(.exe)?}}"
 // CHECK-CFI-CROSS-DSO-ANDROID-NOT: libclang_rt.cfi
 
 // Cross-DSO CFI with diagnostics on Android links just the UBSAN runtime.
@@ -569,7 +569,7 @@
 // RUN: -target aarch64-linux-android -fuse-ld=ld \
 // RUN: --sysroot=%S/Inputs/basic_android_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-CFI-CROSS-DSO-DIAG-ANDROID %s
-// CHECK-CFI-CROSS-DSO-DIAG-ANDROID: "{{.*}}ld{{(.exe)?}}"
+// CHECK-CFI-CROSS-DSO-DIAG-ANDROID: "{{.*}}ld.lld{{(.exe)?}}"
 // CHECK-CFI-CROSS-DSO-DIAG-ANDROID: "{{[^"]*}}libclang_rt.ubsan_standalone-aarch64-android.so"
 // CHECK-CFI-CROSS-DSO-DIAG-ANDROID: "-export-dynamic-symbol=__cfi_check"
 
@@ -673,7 +673,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-SAFESTACK-ANDROID-ARM %s
 //
-// CHECK-SAFESTACK-ANDROID-ARM: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-SAFESTACK-ANDROID-ARM: "{{(.*[^-.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-SAFESTACK-ANDROID-ARM-NOT: libclang_rt.safestack
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o -shared 2>&1 \
@@ -681,7 +681,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-SAFESTACK-SHARED-ANDROID-ARM %s
 //
-// CHECK-SAFESTACK-SHARED-ANDROID-ARM: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-SAFESTACK-SHARED-ANDROID-ARM: "{{(.*[^-.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-SAFESTACK-SHARED-ANDROID-ARM-NOT: libclang_rt.safestack
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1135
+llvm::MD5 Md5;
+Md5.update(getModule().getSourceFileName());
+llvm::MD5::MD5Result R;

tmsriram wrote:
> hubert.reinterpretcast wrote:
> > davidxl wrote:
> > > rnk wrote:
> > > > davidxl wrote:
> > > > > Source filenames are not guaranteed to be unique, or it does contain 
> > > > > the path as well?
> > > > It appears to contain the path as the compiler receives it on the 
> > > > command line. However, it is possible to design a build where this 
> > > > string is not unique:
> > > > ```
> > > > cd foo
> > > > clang -c name_conflict.c 
> > > > cd ../bar
> > > > clang -c name_conflict.c
> > > > clang foo/name_conflict.o bar/name_conflict.o
> > > > ```
> > > > 
> > > > I don't think we should try to handle this case, but we should document 
> > > > the limitation somewhere. Some build systems do operate changing the 
> > > > working directory as they go.
> > > > 
> > > > Can you add some to the clang/docs/UsersManual.rst file? I'd expect it 
> > > > to show up here:
> > > > https://clang.llvm.org/docs/UsersManual.html#command-line-options
> > > > 
> > > > You can elaborate that the unique names are calculated using the source 
> > > > path passed to the compiler, and in a build system where that is not 
> > > > unique, the function names may not be unique.
> > > > 
> > > > ---
> > > > 
> > > > I have also used this construct in the past for building single-file 
> > > > ABI compatibility test cases:
> > > > 
> > > > ```
> > > > // foo.cpp
> > > > #ifdef PART1
> > > > // ...
> > > > #elif defined(PART2)
> > > > // ...
> > > > #endif
> > > > 
> > > > $ cc -c foo.cpp -DPART1
> > > > $ cc -c foo.cpp -DPART2
> > > > ```
> > > yes, the first example was the scenario I meant. I agree name conflict 
> > > due that case should be really rare. If yes, we can always use content 
> > > based uniqueid -- by appending llvm::getUniqueModuleId -- but that is 
> > > probably overkill.
> > > yes, the first example was the scenario I meant. I agree name conflict 
> > > due that case should be really rare.
> > Except for projects where it is the rule and not the exception. One pattern 
> > where this occurs is when each subdirectory implements one class and there 
> > are multiple classes that implement the same interface. In each directory, 
> > the implementation of each class is separated into files by grouping 
> > methods of the class. The set of filenames in one such directory may well 
> > be the same as the set in another.
> I am not sure much can be done here other than try using getUniqueModuleId.  
> Just to be clear, even if the file names are the same, the actual conflict 
> happens only when the "make " is done from the leaf directory.  Doing:
> 
> cc a/name_conflict.cpp -c
> cc b/name_conflict.cpp -c 
> 
> should still produce unique names.
Understood. I do happen to have been working on a project that does the whole 
`$(MAKE) -C a/` thing with such a project layout. Content based hashing is 
unfortunate for other reasons: The hash would be unstable during the course of 
maintenance on the codebase. I guess the limitation is okay for the intended 
use case of the patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76458: Add Indirect Thunk Support to X86 to mitigate Load Value Injection (LVI) [by modifying X86RetpolineThunks.cpp]

[Zola Bridges via Phabricator via cfe-commits]

zbrid added inline comments.



Comment at: llvm/lib/Target/X86/X86.td:437
+: SubtargetFeature<
+  "lvi-cfi", "UseLVIControlFlowIntegrity", "true",
+  "Prevent indirect calls/branches from using a memory operand, and "

Also to follow up on the discussion earlier about SESES using the lvi-cfi 
subtarget feature for mitigating other issues as well.

Would it be possible to rename the subtarget specific to be more generic? I 
came up with a couple options: spex-cfi? speculative execution-cfi? se-cfi? 
side-channel-cfi? I don't know if that's too broad or not precise enough. The 
`lvi-cfi` flag should remain in Clang for sure, but I'd want to enable the 
subtarget feature for SESES which may not be used only for LVI.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76458/new/

https://reviews.llvm.org/D76458



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76365: [cuda][hip] Add CUDA builtin surface/texture reference support.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

I believe LLVM does have `nvvm.texsurf.handle` implemented: 
https://github.com/llvm/llvm-project/blob/d9972f848294b06807c8764615852ba2bc1e8a74/llvm/include/llvm/IR/IntrinsicsNVVM.td#L1150

We also appear to have some plumbing for it in clang: 
https://github.com/llvm/llvm-project/blob/31262d6722c7ae6a9966a76064af43e5b3a8df71/llvm/lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp#L724


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76365/new/

https://reviews.llvm.org/D76365



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76365: [cuda][hip] Add CUDA builtin surface/texture reference support.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

> Note that, clang-based one needs defining texture fetch functions as they 
> could not be reused from CUDA SDK. That part is enclosed with #if 
> defined(__clang__).

What prevents clang to compile the texture functions in the CUDA headers? It 
looks like we'll need to implement the `__nv_tex_surf_handler()` builtin, but 
other than that it should work.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76365/new/

https://reviews.llvm.org/D76365



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76455: [NFC] Refactor handling of Xarch option

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D76455#1932232 , @tra wrote:

> +1 for refactoring, but what's the long term plan.
>  Long time ago echristo@ and I had a vague idea to change clang's option 
> parsing to allow something like ` -Xarch_host  -Xarch_device 
>  -Xarch=  
> only...>`


Yes I have patch for this which is half done.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76455/new/

https://reviews.llvm.org/D76455



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75661: Remove SequentialType from the type heirarchy.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen accepted this revision.
sdesmalen added a comment.
This revision is now accepted and ready to land.

Thank you for this patch! Personally I find the code more readable without the 
SequentialType abstraction and the use of the GEP interface 
(getTypeAtIndex(Type, Idx)) you added in D75660 
.
Like @nhaehnle I don't know whether this patch needs some more eyes before you 
commit this, but it looks good to me!




Comment at: llvm/lib/Transforms/IPO/GlobalOpt.cpp:442
+}
+static uint64_t GetSRASequentialNumElements(Type *T) {
+  if (ArrayType *AT = cast(T))

nit: With only two uses, I'm not sure these functions make the code much more 
readable than just expanding it in their uses below.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75661/new/

https://reviews.llvm.org/D75661



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75010: [OpenMP] Adding InaccessibleMemOnly and InaccessibleMemOrArgMemOnly for runtime calls.

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert accepted this revision.
jdoerfert added a comment.

LGTM if the test all pass.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75010/new/

https://reviews.llvm.org/D75010



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram marked 4 inline comments as done.
tmsriram added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1135
+llvm::MD5 Md5;
+Md5.update(getModule().getSourceFileName());
+llvm::MD5::MD5Result R;

hubert.reinterpretcast wrote:
> davidxl wrote:
> > rnk wrote:
> > > davidxl wrote:
> > > > Source filenames are not guaranteed to be unique, or it does contain 
> > > > the path as well?
> > > It appears to contain the path as the compiler receives it on the command 
> > > line. However, it is possible to design a build where this string is not 
> > > unique:
> > > ```
> > > cd foo
> > > clang -c name_conflict.c 
> > > cd ../bar
> > > clang -c name_conflict.c
> > > clang foo/name_conflict.o bar/name_conflict.o
> > > ```
> > > 
> > > I don't think we should try to handle this case, but we should document 
> > > the limitation somewhere. Some build systems do operate changing the 
> > > working directory as they go.
> > > 
> > > Can you add some to the clang/docs/UsersManual.rst file? I'd expect it to 
> > > show up here:
> > > https://clang.llvm.org/docs/UsersManual.html#command-line-options
> > > 
> > > You can elaborate that the unique names are calculated using the source 
> > > path passed to the compiler, and in a build system where that is not 
> > > unique, the function names may not be unique.
> > > 
> > > ---
> > > 
> > > I have also used this construct in the past for building single-file ABI 
> > > compatibility test cases:
> > > 
> > > ```
> > > // foo.cpp
> > > #ifdef PART1
> > > // ...
> > > #elif defined(PART2)
> > > // ...
> > > #endif
> > > 
> > > $ cc -c foo.cpp -DPART1
> > > $ cc -c foo.cpp -DPART2
> > > ```
> > yes, the first example was the scenario I meant. I agree name conflict due 
> > that case should be really rare. If yes, we can always use content based 
> > uniqueid -- by appending llvm::getUniqueModuleId -- but that is probably 
> > overkill.
> > yes, the first example was the scenario I meant. I agree name conflict due 
> > that case should be really rare.
> Except for projects where it is the rule and not the exception. One pattern 
> where this occurs is when each subdirectory implements one class and there 
> are multiple classes that implement the same interface. In each directory, 
> the implementation of each class is separated into files by grouping methods 
> of the class. The set of filenames in one such directory may well be the same 
> as the set in another.
I am not sure much can be done here other than try using getUniqueModuleId.  
Just to be clear, even if the file names are the same, the actual conflict 
happens only when the "make " is done from the leaf directory.  Doing:

cc a/name_conflict.cpp -c
cc b/name_conflict.cpp -c 

should still produce unique names.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76458: Add Indirect Thunk Support to X86 to mitigate Load Value Injection (LVI) [by modifying X86RetpolineThunks.cpp]

[Zola Bridges via Phabricator via cfe-commits]

zbrid added a comment.

I commented on the other patch about this before I saw this patch. Thanks for 
putting this up!

I think it looks pretty good, but could you do a more full refactor of the 
retpolinethunks pass in an NFC patch? Then have the LVI functionality added on 
top of that refactored patch?

S




Comment at: llvm/lib/Target/X86/X86Subtarget.h:870
   bool enableIndirectBrExpand() const override {
-return useRetpolineIndirectBranches();
+return useRetpolineIndirectBranches() || useLVIControlFlowIntegrity();
   }

Probably can be changed to checking whether we are using indirect branch 
thunking, etc. I think there were a few other conditionals relating to 
retpolines that may also need to be changed. The renaming you did in the first 
indirect branch pass for some functions (ef EmitLoweredRetpoline -> 
EmitLoweredThunk) should perhaps also be preserved in whatever update you do.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76458/new/

https://reviews.llvm.org/D76458



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76189: [Fuchsia] Use -ffile-prefix-map

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG98223f7931f2: [Fuchsia] Use -ffile-prefix-map (authored by 
phosek).

Changed prior to commit:
  https://reviews.llvm.org/D76189?vs=250401=251491#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76189/new/

https://reviews.llvm.org/D76189

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -16,7 +16,7 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 set(LLVM_INCLUDE_GO_TESTS OFF CACHE BOOL "")
-set(LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO ON CACHE BOOL "")
+set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
 
 set(CLANG_DEFAULT_CXX_STDLIB libc++ CACHE STRING "")
 if(NOT APPLE)


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -16,7 +16,7 @@
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 set(LLVM_INCLUDE_GO_TESTS OFF CACHE BOOL "")
-set(LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO ON CACHE BOOL "")
+set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
 
 set(CLANG_DEFAULT_CXX_STDLIB libc++ CACHE STRING "")
 if(NOT APPLE)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76365: [cuda][hip] Add CUDA builtin surface/texture reference support.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

With this revision, the following sample could be compiled with CUDA SDK and 
almost the same PTX code is generated.

  #include 
  
  texture tex;
  
  #if defined(__clang__)
  struct v4f {
float x, y, z, w;
  };
  __device__ v4f
  tex_2d_ld(texture,
float, float) asm("llvm.nvvm.tex.unified.2d.v4f32.f32");
  
  template 
  static inline __device__ T
  tex2D(texture t,
float x, float y) {
return tex_2d_ld(t, x, y).x;
  }
  #endif
  
  __device__ float foo(float x, float y) { return tex2D(tex, x, y); }

Note that, clang-based one needs defining texture fetch functions as they could 
not be reused from CUDA SDK. That part is enclosed with `#if 
defined(__clang__)`.

Here's the PTX code generated from NVCC. ``

  kernel.ptx
  //
  // Generated by NVIDIA NVVM Compiler
  //
  // Compiler Build ID: CL-27506705
  // Cuda compilation tools, release 10.2, V10.2.89
  // Based on LLVM 3.4svn
  //
  
  .version 6.5
  .target sm_30
  .address_size 64
  
  // .globl   _Z3fooff
  .visible .global .texref tex;
  
  .visible .func  (.param .b32 func_retval0) _Z3fooff(
  .param .b32 _Z3fooff_param_0,
  .param .b32 _Z3fooff_param_1
  )
  {
  .reg .f32   %f<7>;
  .reg .b64   %rd<2>;
  
  
  ld.param.f32%f1, [_Z3fooff_param_0];
  ld.param.f32%f2, [_Z3fooff_param_1];
  tex.2d.v4.f32.f32   {%f3, %f4, %f5, %f6}, [tex, {%f1, %f2}];
  st.param.f32[func_retval0+0], %f3;
  ret;
  }

Here's the PTX code generated from Clang and LLVM backend. `clang 
--cuda-device-only --cuda-gpu-arch=sm_30 -O2 -S kernel.cu`

  kernel-cuda-nvptx64-nvidia-cuda-sm_30.s
  //
  // Generated by LLVM NVPTX Back-End
  //
  
  .version 6.4
  .target sm_30
  .address_size 64
  
  // .globl   _Z3fooff
  .visible .global .texref tex;
  
  .visible .func  (.param .b32 func_retval0) _Z3fooff(
  .param .b32 _Z3fooff_param_0,
  .param .b32 _Z3fooff_param_1
  )
  {
  .reg .f32   %f<7>;
  .reg .b64   %rd<2>;
  
  ld.param.f32%f1, [_Z3fooff_param_0];
  ld.param.f32%f2, [_Z3fooff_param_1];
  mov.u64 %rd1, tex;
  tex.2d.v4.f32.f32   {%f3, %f4, %f5, %f6}, [%rd1, {%f1, %f2}];
  st.param.f32[func_retval0+0], %f3;
  ret;
  
  }


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76365/new/

https://reviews.llvm.org/D76365



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76438: ConstantExpr cached APValues if present for constant evaluation

[Wyatt Childers via Phabricator via cfe-commits]

wchilders marked an inline comment as done.
wchilders added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:7329
+  if (Result.isLValue())
+return Success(Result, E);
+}

rsmith wrote:
> wchilders wrote:
> > This doesn't seem to be the right answer, and `ConstantExpr`s don't have 
> > `LValue` `APValue`s, at least, not that are reaching this case. We had a 
> > previous implementation that also, kind of punted on this issue with an 
> > override in `TemporaryExprEvaluator`: 
> > https://gitlab.com/lock3/clang/-/blob/9fbaeea06fc567ac472264bec2a72661a1e06c73/clang/lib/AST/ExprConstant.cpp#L9753
> The base class version seems appropriate to me, even for this case. We 
> eventually want to use `ConstantExpr` to store the evaluated initializer 
> value of a `constexpr` variable (replacing the existing special-case caching 
> on `VarDecl`) and the like, not only for immediate invocations, and once we 
> start doing that for reference variables we'll have glvalue `ConstantExpr`s.
> 
> Is there some circumstance under which a glvalue `ConstantExpr`'s `APValue` 
> result is not of kind `LValue`?
> Is there some circumstance under which a glvalue ConstantExpr's APValue 
> result is not of kind LValue?

Good question, the `Sema/switch.c` test fails if you 
`assert(Result.isLValue())`.

```
ConstantExpr 0x62ab8760 'const int' lvalue Int: 3
`-DeclRefExpr 0x62ab8740 'const int' lvalue Var 0x62ab8230 'a' 'const 
int'
```

With an attributed line no. 359: 
https://github.com/llvm/llvm-project/blob/4b0029995853fe37d1dc95ef96f46697c743fcad/clang/test/Sema/switch.c#L359

The offending RValue is created in SemaExpr.cpp here: 
https://github.com/llvm/llvm-project/blob/f87563661d6661fd4843beb8f391acd077b08dbe/clang/lib/Sema/SemaExpr.cpp#L15190

The issue stems from evaluating this as an RValue to produce an integer, then 
caching that RValue in an lvalue constant expression. Do you have any 
suggestions? Perhaps an LValue to RValue conversion should be performed on the 
expression if it folds correctly, so that the ConstantExpr is actually an 
RValue?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76438/new/

https://reviews.llvm.org/D76438



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76365: [cuda][hip] Add CUDA builtin surface/texture reference support.

[Michael Liao via Phabricator via cfe-commits]

hliao updated this revision to Diff 251488.
hliao added a comment.

More refinement to compile sample code with CUDA headers.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76365/new/

https://reviews.llvm.org/D76365

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/AST/Type.cpp
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CGCUDARuntime.h
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/CodeGen/TargetInfo.h
  clang/lib/Headers/__clang_cuda_runtime_wrapper.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGenCUDA/surface.cu
  clang/test/CodeGenCUDA/texture.cu
  clang/test/SemaCUDA/attr-declspec.cu
  clang/test/SemaCUDA/attributes-on-non-cuda.cu
  llvm/include/llvm/IR/Operator.h

Index: llvm/include/llvm/IR/Operator.h
===
--- llvm/include/llvm/IR/Operator.h
+++ llvm/include/llvm/IR/Operator.h
@@ -599,6 +599,25 @@
   }
 };
 
+class AddrSpaceCastOperator
+: public ConcreteOperator {
+  friend class AddrSpaceCastInst;
+  friend class ConstantExpr;
+
+public:
+  Value *getPointerOperand() { return getOperand(0); }
+
+  const Value *getPointerOperand() const { return getOperand(0); }
+
+  unsigned getSrcAddressSpace() const {
+return getPointerOperand()->getType()->getPointerAddressSpace();
+  }
+
+  unsigned getDestAddressSpace() const {
+return getType()->getPointerAddressSpace();
+  }
+};
+
 } // end namespace llvm
 
 #endif // LLVM_IR_OPERATOR_H
Index: clang/test/SemaCUDA/attributes-on-non-cuda.cu
===
--- clang/test/SemaCUDA/attributes-on-non-cuda.cu
+++ clang/test/SemaCUDA/attributes-on-non-cuda.cu
@@ -7,16 +7,21 @@
 // RUN: %clang_cc1 -DEXPECT_WARNINGS -fsyntax-only -verify -x c %s
 
 #if defined(EXPECT_WARNINGS)
-// expected-warning@+12 {{'device' attribute ignored}}
-// expected-warning@+12 {{'global' attribute ignored}}
-// expected-warning@+12 {{'constant' attribute ignored}}
-// expected-warning@+12 {{'shared' attribute ignored}}
-// expected-warning@+12 {{'host' attribute ignored}}
+// expected-warning@+17 {{'device' attribute ignored}}
+// expected-warning@+17 {{'global' attribute ignored}}
+// expected-warning@+17 {{'constant' attribute ignored}}
+// expected-warning@+17 {{'shared' attribute ignored}}
+// expected-warning@+17 {{'host' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_surface_type' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_texture_type' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_surface_type' attribute ignored}}
+// expected-warning@+23 {{'device_builtin_texture_type' attribute ignored}}
 //
 // NOTE: IgnoredAttr in clang which is used for the rest of
 // attributes ignores LangOpts, so there are no warnings.
 #else
-// expected-no-diagnostics
+// expected-warning@+15 {{'device_builtin_surface_type' attribute only applies to types}}
+// expected-warning@+15 {{'device_builtin_texture_type' attribute only applies to types}}
 #endif
 
 __attribute__((device)) void f_device();
@@ -32,3 +37,5 @@
 __attribute__((nv_weak)) void f_nv_weak();
 __attribute__((device_builtin_surface_type)) unsigned long long surface_var;
 __attribute__((device_builtin_texture_type)) unsigned long long texture_var;
+struct __attribute__((device_builtin_surface_type)) surf_ref {};
+struct __attribute__((device_builtin_texture_type)) tex_ref {};
Index: clang/test/SemaCUDA/attr-declspec.cu
===
--- clang/test/SemaCUDA/attr-declspec.cu
+++ clang/test/SemaCUDA/attr-declspec.cu
@@ -6,16 +6,21 @@
 // RUN: %clang_cc1 -DEXPECT_WARNINGS -fms-extensions -fsyntax-only -verify -x c %s
 
 #if defined(EXPECT_WARNINGS)
-// expected-warning@+12 {{'__device__' attribute ignored}}
-// expected-warning@+12 {{'__global__' attribute ignored}}
-// expected-warning@+12 {{'__constant__' attribute ignored}}
-// expected-warning@+12 {{'__shared__' attribute ignored}}
-// expected-warning@+12 {{'__host__' attribute ignored}}
+// expected-warning@+17 {{'__device__' attribute ignored}}
+// expected-warning@+17 {{'__global__' attribute ignored}}
+// expected-warning@+17 {{'__constant__' attribute ignored}}
+// expected-warning@+17 {{'__shared__' attribute ignored}}
+// expected-warning@+17 {{'__host__' attribute ignored}}
+// expected-warning@+22 {{'__device_builtin_surface_type__' attribute ignored}}
+// expected-warning@+22 {{'__device_builtin_texture_type__' attribute ignored}}
+// expected-warning@+22 {{'__device_builtin_surface_type__' attribute ignored}}
+// expected-warning@+22 {{'__device_builtin_texture_type__' attribute ignored}}
 //
 // (Currently we don't for the other attributes. They are implemented with
 // IgnoredAttr, which is 

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/test/CodeGen/unique-internal-funcnames.c:3
+
+// RUN: %clang -target x86_64 -S -o - %s | FileCheck %s --check-prefix=PLAIN
+// RUN: %clang -target x86_64 -S -funique-internal-funcnames -o -  %s | 
FileCheck %s --check-prefix=UNIQUE

rnk wrote:
> tmsriram wrote:
> > davidxl wrote:
> > > MaskRay wrote:
> > > > You can hardly find any .c -> .s test in clang/test. We mostly do .c -> 
> > > > .ll testing. `.ll` -> `.s` are in llvm/test/CodeGen. 
> > > Is this convention documented somewhere? Any concerns of producing .s?
> > There are more than 200 tests in clang that do -S from .c -> .s and tens of 
> > tests in CodeGen alone.  I can change this to .ll but curious where this 
> > "hardly any" comes from?
> I can't specifically find documentation for this convention, but it is 
> generally understood that every feature should have targeted unit tests that 
> exercise the minimum amount of functionality. In this case, that means using 
> `%clang_cc1 -emit-llvm -triple NNN` and checking the IR.
Not that many -S .c -> .s tests (`rg '%clang.* -S ' | egrep -v 
'[-]###|emit-llvm|-verify' | awk -F: '{print $1}' | sort -u | wc -l`). Many are 
about -emit-llvm -### -verify or misused -v. They do not need to produce 
assembly.



Comment at: clang/test/Driver/funique-internal-funcnames.c:4
+// CHECK-OPT: "-funique-internal-funcnames"
+// CHECK-NOOPT-NOT: {{-funique-internal-funcnames}}

This negative pattern needs to be changed as well.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75934: Add Indirect Thunk Support to X86 to mitigate Load Value Injection (LVI) [2/6]

[Zola Bridges via Phabricator via cfe-commits]

zbrid added a comment.

I followed up with Chandler about whether it would make sense to integrate this 
with the existing retpolines pass as you and Craig suggested. He supported the 
idea. Could you create a new patch(es) to do the refactor/renaming of the 
retpolines thunking pass and instruction scheduling conditionals to be more 
general and then add the LVI option?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75934/new/

https://reviews.llvm.org/D75934



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1135
+llvm::MD5 Md5;
+Md5.update(getModule().getSourceFileName());
+llvm::MD5::MD5Result R;

davidxl wrote:
> rnk wrote:
> > davidxl wrote:
> > > Source filenames are not guaranteed to be unique, or it does contain the 
> > > path as well?
> > It appears to contain the path as the compiler receives it on the command 
> > line. However, it is possible to design a build where this string is not 
> > unique:
> > ```
> > cd foo
> > clang -c name_conflict.c 
> > cd ../bar
> > clang -c name_conflict.c
> > clang foo/name_conflict.o bar/name_conflict.o
> > ```
> > 
> > I don't think we should try to handle this case, but we should document the 
> > limitation somewhere. Some build systems do operate changing the working 
> > directory as they go.
> > 
> > Can you add some to the clang/docs/UsersManual.rst file? I'd expect it to 
> > show up here:
> > https://clang.llvm.org/docs/UsersManual.html#command-line-options
> > 
> > You can elaborate that the unique names are calculated using the source 
> > path passed to the compiler, and in a build system where that is not 
> > unique, the function names may not be unique.
> > 
> > ---
> > 
> > I have also used this construct in the past for building single-file ABI 
> > compatibility test cases:
> > 
> > ```
> > // foo.cpp
> > #ifdef PART1
> > // ...
> > #elif defined(PART2)
> > // ...
> > #endif
> > 
> > $ cc -c foo.cpp -DPART1
> > $ cc -c foo.cpp -DPART2
> > ```
> yes, the first example was the scenario I meant. I agree name conflict due 
> that case should be really rare. If yes, we can always use content based 
> uniqueid -- by appending llvm::getUniqueModuleId -- but that is probably 
> overkill.
> yes, the first example was the scenario I meant. I agree name conflict due 
> that case should be really rare.
Except for projects where it is the rule and not the exception. One pattern 
where this occurs is when each subdirectory implements one class and there are 
multiple classes that implement the same interface. In each directory, the 
implementation of each class is separated into files by grouping methods of the 
class. The set of filenames in one such directory may well be the same as the 
set in another.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76458: Add Indirect Thunk Support to X86 to mitigate Load Value Injection (LVI) [by modifying X86RetpolineThunks.cpp]

[Scott Constable via Phabricator via cfe-commits]

sconstab created this revision.
sconstab added reviewers: zbrid, craig.topper, andrew.w.kaylor, chandlerc.
Herald added subscribers: jfb, hiraditya.

This patch is an alternate implementation of D75934 
 that mitigates LVI indirect calls/jumps by 
making changes to the existing X86RetpolineThunks pass, instead of introducing 
a new pass.


https://reviews.llvm.org/D76458

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Arch/X86.cpp
  llvm/lib/Target/X86/X86.td
  llvm/lib/Target/X86/X86RetpolineThunks.cpp
  llvm/lib/Target/X86/X86Subtarget.h
  llvm/test/CodeGen/X86/lvi-hardening-indirectbr.ll

Index: llvm/test/CodeGen/X86/lvi-hardening-indirectbr.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/lvi-hardening-indirectbr.ll
@@ -0,0 +1,281 @@
+; RUN: llc -verify-machineinstrs -mtriple=x86_64-unknown -mattr=+lvi-cfi < %s | FileCheck %s --check-prefix=X64
+; RUN: llc -verify-machineinstrs -mtriple=x86_64-unknown -mattr=+lvi-cfi -O0 < %s | FileCheck %s --check-prefix=X64FAST
+;
+; Note that a lot of this code was lifted from retpoline.ll.
+
+declare void @bar(i32)
+
+; Test a simple indirect call and tail call.
+define void @icall_reg(void (i32)* %fp, i32 %x) {
+entry:
+  tail call void @bar(i32 %x)
+  tail call void %fp(i32 %x)
+  tail call void @bar(i32 %x)
+  tail call void %fp(i32 %x)
+  ret void
+}
+
+; X64-LABEL: icall_reg:
+; X64-DAG:   movq %rdi, %[[fp:[^ ]*]]
+; X64-DAG:   movl %esi, %[[x:[^ ]*]]
+; X64:   movl %esi, %edi
+; X64:   callq bar
+; X64-DAG:   movl %[[x]], %edi
+; X64-DAG:   movq %[[fp]], %r11
+; X64:   callq __llvm_retpoline_r11
+; X64:   movl %[[x]], %edi
+; X64:   callq bar
+; X64-DAG:   movl %[[x]], %edi
+; X64-DAG:   movq %[[fp]], %r11
+; X64:   jmp __llvm_retpoline_r11 # TAILCALL
+
+; X64FAST-LABEL: icall_reg:
+; X64FAST:   callq bar
+; X64FAST:   callq __llvm_retpoline_r11
+; X64FAST:   callq bar
+; X64FAST:   jmp __llvm_retpoline_r11 # TAILCALL
+
+
+@global_fp = external global void (i32)*
+
+; Test an indirect call through a global variable.
+define void @icall_global_fp(i32 %x, void (i32)** %fpp) #0 {
+  %fp1 = load void (i32)*, void (i32)** @global_fp
+  call void %fp1(i32 %x)
+  %fp2 = load void (i32)*, void (i32)** @global_fp
+  tail call void %fp2(i32 %x)
+  ret void
+}
+
+; X64-LABEL: icall_global_fp:
+; X64-DAG:   movl %edi, %[[x:[^ ]*]]
+; X64-DAG:   movq global_fp(%rip), %r11
+; X64:   callq __llvm_retpoline_r11
+; X64-DAG:   movl %[[x]], %edi
+; X64-DAG:   movq global_fp(%rip), %r11
+; X64:   jmp __llvm_retpoline_r11 # TAILCALL
+
+; X64FAST-LABEL: icall_global_fp:
+; X64FAST:   movq global_fp(%rip), %r11
+; X64FAST:   callq __llvm_retpoline_r11
+; X64FAST:   movq global_fp(%rip), %r11
+; X64FAST:   jmp __llvm_retpoline_r11 # TAILCALL
+
+
+%struct.Foo = type { void (%struct.Foo*)** }
+
+; Test an indirect call through a vtable.
+define void @vcall(%struct.Foo* %obj) #0 {
+  %vptr_field = getelementptr %struct.Foo, %struct.Foo* %obj, i32 0, i32 0
+  %vptr = load void (%struct.Foo*)**, void (%struct.Foo*)*** %vptr_field
+  %vslot = getelementptr void(%struct.Foo*)*, void(%struct.Foo*)** %vptr, i32 1
+  %fp = load void(%struct.Foo*)*, void(%struct.Foo*)** %vslot
+  tail call void %fp(%struct.Foo* %obj)
+  tail call void %fp(%struct.Foo* %obj)
+  ret void
+}
+
+; X64-LABEL: vcall:
+; X64:   movq %rdi, %[[obj:[^ ]*]]
+; X64:   movq (%rdi), %[[vptr:[^ ]*]]
+; X64:   movq 8(%[[vptr]]), %[[fp:[^ ]*]]
+; X64:   movq %[[fp]], %r11
+; X64:   callq __llvm_retpoline_r11
+; X64-DAG:   movq %[[obj]], %rdi
+; X64-DAG:   movq %[[fp]], %r11
+; X64:   jmp __llvm_retpoline_r11 # TAILCALL
+
+; X64FAST-LABEL: vcall:
+; X64FAST:   callq __llvm_retpoline_r11
+; X64FAST:   jmp __llvm_retpoline_r11 # TAILCALL
+
+
+declare void @direct_callee()
+
+define void @direct_tail() #0 {
+  tail call void @direct_callee()
+  ret void
+}
+
+; X64-LABEL: direct_tail:
+; X64:   jmp direct_callee # TAILCALL
+; X64FAST-LABEL: direct_tail:
+; X64FAST:   jmp direct_callee # TAILCALL
+
+
+declare void @nonlazybind_callee() #1
+
+define void @nonlazybind_caller() #0 {
+  call void @nonlazybind_callee()
+  tail call void @nonlazybind_callee()
+  ret void
+}
+
+; X64-LABEL: nonlazybind_caller:
+; X64:   movq nonlazybind_callee@GOTPCREL(%rip), %[[REG:.*]]
+; X64:   movq %[[REG]], %r11
+; X64:   callq __llvm_retpoline_r11
+; X64:   movq %[[REG]], %r11
+; X64:   jmp __llvm_retpoline_r11 # TAILCALL
+; X64FAST-LABEL: nonlazybind_caller:
+; X64FAST:   movq nonlazybind_callee@GOTPCREL(%rip), %r11
+; X64FAST:   callq __llvm_retpoline_r11
+; X64FAST:   movq nonlazybind_callee@GOTPCREL(%rip), %r11
+; X64FAST:   jmp __llvm_retpoline_r11 # TAILCALL
+
+
+; Check that a switch gets lowered using a jump table
+define void @switch_jumptable(i32* %ptr, i64* %sink) #0 {
+; X64-LABEL: 

[PATCH] D76455: [NFC] Refactor handling of Xarch option

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

+1 for refactoring, but what's the long term plan.
Long time ago echristo@ and I had a vague idea to change clang's option parsing 
to allow something like ` -Xarch_host  -Xarch_device  -Xarch=  only...>`


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76455/new/

https://reviews.llvm.org/D76455



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76140: [InlineFunction] update attributes during inlining

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: llvm/lib/Transforms/Utils/InlineFunction.cpp:1172
+return true;
+return false;
+  };

`mayThrow` is not sufficient. As with my earlier example, a potential `exit` is 
sufficient to break this, thus you need `willreturn` as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76140/new/

https://reviews.llvm.org/D76140



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D60748: Adds an option "malign-pass-aggregate" to make the alignment of the struct and union parameters compatible with the default gcc

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: clang/include/clang/Basic/LangOptions.def:353
 
+VALUE_LANGOPT(AlignPassingAggregate, 1, 0, "Compatible with gcc default 
passing struct and union (x86 only).")
+

If only codegen needs to know, a CodeGenOption would be better.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:1556
+
+  for (RecordDecl::field_iterator i = RD->field_begin(), e = 
RD->field_end();
+   i != e; ++i) {

Any time you crack open a record to look at the fields, the code is probably 
wrong the first time you write it. :( In this case, I suspect you are not 
looking at base classes. Consider:
```
struct A {
  MyAlignedType Field;
};
struct B : A {};
void passbyval(B o);
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60748/new/

https://reviews.llvm.org/D60748



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 98223f7 - [Fuchsia] Use -ffile-prefix-map

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2020-03-19T15:14:15-07:00
New Revision: 98223f7931f263a38435c51c026d7dcd9bf11a68

URL: 
https://github.com/llvm/llvm-project/commit/98223f7931f263a38435c51c026d7dcd9bf11a68
DIFF: 
https://github.com/llvm/llvm-project/commit/98223f7931f263a38435c51c026d7dcd9bf11a68.diff

LOG: [Fuchsia] Use -ffile-prefix-map

This makes toolchain independent of the path it was built in by
rewriting all absolute paths embedded in sources and debug info
into relative ones.

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

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index 7733e55ab229..e2be68be2284 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -16,7 +16,7 @@ set(LLVM_ENABLE_ZLIB ON CACHE BOOL "")
 set(LLVM_INCLUDE_DOCS OFF CACHE BOOL "")
 set(LLVM_INCLUDE_EXAMPLES OFF CACHE BOOL "")
 set(LLVM_INCLUDE_GO_TESTS OFF CACHE BOOL "")
-set(LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO ON CACHE BOOL "")
+set(LLVM_USE_RELATIVE_PATHS_IN_FILES ON CACHE BOOL "")
 
 set(CLANG_DEFAULT_CXX_STDLIB libc++ CACHE STRING "")
 if(NOT APPLE)



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76098: [clangd] Do not trigger go-to-def textual fallback inside string literals

[Nathan Ridge via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb89202e842ac: [clangd] Do not trigger go-to-def textual 
fallback inside string literals (authored by nridge).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76098/new/

https://reviews.llvm.org/D76098

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -644,7 +644,8 @@
 // Comment mentioning M^yClass
   )cpp",
   R"cpp(// String
-struct [[MyClass]] {};
+struct MyClass {};
+// Not triggered for string literal tokens.
 const char* s = "String literal mentioning M^yClass";
   )cpp",
   R"cpp(// Ifdef'ed out code
@@ -696,7 +697,7 @@
   EXPECT_EQ(Results[0].PreferredDeclaration.range, *WantDecl) << Test;
 }
   }
-}
+} // namespace
 
 TEST(LocateSymbol, Ambiguous) {
   auto T = Annotations(R"cpp(
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -374,6 +374,18 @@
   unsigned WordOffset = Word.data() - Code.data();
   SourceLocation WordStart = SM.getComposedLoc(File, WordOffset);
 
+  // Attempt to determine the kind of token that contains the word,
+  // and bail if it's a string literal. Note that we cannot always
+  // determine the token kind (e.g. comments, for which we do want
+  // to activate, are not retained by TokenBuffer).
+  for (syntax::Token T :
+   syntax::spelledTokensTouching(WordStart, AST.getTokens())) {
+if (T.range(AST.getSourceManager()).touches(WordOffset + Word.size())) {
+  if (isStringLiteral(T.kind()))
+return {};
+}
+  }
+
   // Do not consider tokens that survived preprocessing.
   // We are erring on the safe side here, as a user may expect to get
   // accurate (as opposed to textual-heuristic) results for such tokens.


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -644,7 +644,8 @@
 // Comment mentioning M^yClass
   )cpp",
   R"cpp(// String
-struct [[MyClass]] {};
+struct MyClass {};
+// Not triggered for string literal tokens.
 const char* s = "String literal mentioning M^yClass";
   )cpp",
   R"cpp(// Ifdef'ed out code
@@ -696,7 +697,7 @@
   EXPECT_EQ(Results[0].PreferredDeclaration.range, *WantDecl) << Test;
 }
   }
-}
+} // namespace
 
 TEST(LocateSymbol, Ambiguous) {
   auto T = Annotations(R"cpp(
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -374,6 +374,18 @@
   unsigned WordOffset = Word.data() - Code.data();
   SourceLocation WordStart = SM.getComposedLoc(File, WordOffset);
 
+  // Attempt to determine the kind of token that contains the word,
+  // and bail if it's a string literal. Note that we cannot always
+  // determine the token kind (e.g. comments, for which we do want
+  // to activate, are not retained by TokenBuffer).
+  for (syntax::Token T :
+   syntax::spelledTokensTouching(WordStart, AST.getTokens())) {
+if (T.range(AST.getSourceManager()).touches(WordOffset + Word.size())) {
+  if (isStringLiteral(T.kind()))
+return {};
+}
+  }
+
   // Do not consider tokens that survived preprocessing.
   // We are erring on the safe side here, as a user may expect to get
   // accurate (as opposed to textual-heuristic) results for such tokens.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[David Li via Phabricator via cfe-commits]

davidxl added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1135
+llvm::MD5 Md5;
+Md5.update(getModule().getSourceFileName());
+llvm::MD5::MD5Result R;

rnk wrote:
> davidxl wrote:
> > Source filenames are not guaranteed to be unique, or it does contain the 
> > path as well?
> It appears to contain the path as the compiler receives it on the command 
> line. However, it is possible to design a build where this string is not 
> unique:
> ```
> cd foo
> clang -c name_conflict.c 
> cd ../bar
> clang -c name_conflict.c
> clang foo/name_conflict.o bar/name_conflict.o
> ```
> 
> I don't think we should try to handle this case, but we should document the 
> limitation somewhere. Some build systems do operate changing the working 
> directory as they go.
> 
> Can you add some to the clang/docs/UsersManual.rst file? I'd expect it to 
> show up here:
> https://clang.llvm.org/docs/UsersManual.html#command-line-options
> 
> You can elaborate that the unique names are calculated using the source path 
> passed to the compiler, and in a build system where that is not unique, the 
> function names may not be unique.
> 
> ---
> 
> I have also used this construct in the past for building single-file ABI 
> compatibility test cases:
> 
> ```
> // foo.cpp
> #ifdef PART1
> // ...
> #elif defined(PART2)
> // ...
> #endif
> 
> $ cc -c foo.cpp -DPART1
> $ cc -c foo.cpp -DPART2
> ```
yes, the first example was the scenario I meant. I agree name conflict due that 
case should be really rare. If yes, we can always use content based uniqueid -- 
by appending llvm::getUniqueModuleId -- but that is probably overkill.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76424: [AST] Use TypeDependence bitfield to calculate dependence on Types. NFC

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang/include/clang/AST/Type.h:2882
-  Pointee->isInstantiationDependentType()),
- Pointee->isVariablyModifiedType(),
- (Cls->containsUnexpandedParameterPack() ||

hokein wrote:
> we have behavior change for VariableModified bit, now it is `Cls|Pointee` vs 
> `Pointee` before
Good catch!



Comment at: clang/lib/AST/Type.cpp:3036
 
-if (epi.ExceptionSpec.NoexceptExpr->isValueDependent() ||
-epi.ExceptionSpec.NoexceptExpr->isInstantiationDependent())

hokein wrote:
> when converting an ExprDep to TypeDep, we simply drop the value-dependent 
> bit, so here we will not set the instantiation-bit for typeDep if  
> NoexceptExpr is value dependent but not instantiation-dependent.
> if NoexceptExpr is value dependent but not instantiation-dependent.

This never happens - value-dependence implies instantiation-dependence.
(I'm not sure instantiation-dependence is a concept from the standard - maybe 
it just affects diagnostic quality - but 
https://itanium-cxx-abi.github.io/cxx-abi/abi.html is referring to the same 
concept that clang uses.)

(Incidentally this means we could model instantiation/value/type dependence as 
as `unsigned : 2` - this would save a bit and make some of the logic clearer, 
like that "turn type to value dependence" is a downgrade)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76424/new/

https://reviews.llvm.org/D76424



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76424: [AST] Use TypeDependence bitfield to calculate dependence on Types. NFC

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 251478.
sammccall marked 5 inline comments as done.
sammccall added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76424/new/

https://reviews.llvm.org/D76424

Files:
  clang/include/clang/AST/DependenceFlags.h
  clang/include/clang/AST/LocInfoType.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/Type.cpp

Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -20,6 +20,7 @@
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclTemplate.h"
+#include "clang/AST/DependenceFlags.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/NestedNameSpecifier.h"
 #include "clang/AST/NonTrivialTypeVisitor.h"
@@ -123,14 +124,15 @@
 //
 //   template int arr[] = {N...};
 : Type(tc, can,
-   et->isDependentType() || (sz && sz->isValueDependent()) ||
-   tc == DependentSizedArray,
-   et->isInstantiationDependentType() ||
-   (sz && sz->isInstantiationDependent()) ||
-   tc == DependentSizedArray,
-   (tc == VariableArray || et->isVariablyModifiedType()),
-   et->containsUnexpandedParameterPack() ||
-   (sz && sz->containsUnexpandedParameterPack())),
+   et->getDependence() |
+   (sz ? toTypeDependence(
+ turnValueToTypeDependence(sz->getDependence()))
+   : TypeDependence::None) |
+   (tc == VariableArray ? TypeDependence::VariablyModified
+: TypeDependence::None) |
+   (tc == DependentSizedArray
+? TypeDependence::DependentInstantiation
+: TypeDependence::None)),
   ElementType(et) {
   ArrayTypeBits.IndexTypeQuals = tq;
   ArrayTypeBits.SizeModifier = sm;
@@ -217,14 +219,16 @@
   E->Profile(ID, Context, true);
 }
 
-DependentVectorType::DependentVectorType(
-const ASTContext , QualType ElementType, QualType CanonType,
-Expr *SizeExpr, SourceLocation Loc, VectorType::VectorKind VecKind)
-: Type(DependentVector, CanonType, /*Dependent=*/true,
-   /*InstantiationDependent=*/true,
-   ElementType->isVariablyModifiedType(),
-   ElementType->containsUnexpandedParameterPack() ||
-   (SizeExpr && SizeExpr->containsUnexpandedParameterPack())),
+DependentVectorType::DependentVectorType(const ASTContext ,
+ QualType ElementType,
+ QualType CanonType, Expr *SizeExpr,
+ SourceLocation Loc,
+ VectorType::VectorKind VecKind)
+: Type(DependentVector, CanonType,
+   TypeDependence::DependentInstantiation |
+   ElementType->getDependence() |
+   (SizeExpr ? toTypeDependence(SizeExpr->getDependence())
+ : TypeDependence::None)),
   Context(Context), ElementType(ElementType), SizeExpr(SizeExpr), Loc(Loc) {
   VectorTypeBits.VecKind = VecKind;
 }
@@ -238,19 +242,16 @@
   SizeExpr->Profile(ID, Context, true);
 }
 
-DependentSizedExtVectorType::DependentSizedExtVectorType(const
- ASTContext ,
- QualType ElementType,
- QualType can,
- Expr *SizeExpr,
- SourceLocation loc)
-: Type(DependentSizedExtVector, can, /*Dependent=*/true,
-   /*InstantiationDependent=*/true,
-   ElementType->isVariablyModifiedType(),
-   (ElementType->containsUnexpandedParameterPack() ||
-(SizeExpr && SizeExpr->containsUnexpandedParameterPack(,
-  Context(Context), SizeExpr(SizeExpr), ElementType(ElementType),
-  loc(loc) {}
+DependentSizedExtVectorType::DependentSizedExtVectorType(
+const ASTContext , QualType ElementType, QualType can,
+Expr *SizeExpr, SourceLocation loc)
+: Type(DependentSizedExtVector, can,
+   TypeDependence::DependentInstantiation |
+   ElementType->getDependence() |
+   (SizeExpr ? toTypeDependence(SizeExpr->getDependence())
+ : TypeDependence::None)),
+  Context(Context), SizeExpr(SizeExpr), ElementType(ElementType), loc(loc) {
+}
 
 void
 DependentSizedExtVectorType::Profile(llvm::FoldingSetNodeID ,
@@ -260,15 +261,16 @@
   SizeExpr->Profile(ID, Context, true);
 }
 
-DependentAddressSpaceType::DependentAddressSpaceType(
-const ASTContext , QualType PointeeType, QualType can,
-Expr *AddrSpaceExpr, 

[PATCH] D76098: [clangd] Do not trigger go-to-def textual fallback inside string literals

[Nathan Ridge via Phabricator via cfe-commits]

nridge updated this revision to Diff 251476.
nridge added a comment.

Use WordStart


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76098/new/

https://reviews.llvm.org/D76098

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -628,7 +628,8 @@
 // Comment mentioning M^yClass
   )cpp",
   R"cpp(// String
-struct [[MyClass]] {};
+struct MyClass {};
+// Not triggered for string literal tokens.
 const char* s = "String literal mentioning M^yClass";
   )cpp",
   R"cpp(// Ifdef'ed out code
@@ -680,7 +681,7 @@
   EXPECT_EQ(Results[0].PreferredDeclaration.range, *WantDecl) << Test;
 }
   }
-}
+} // namespace
 
 TEST(LocateSymbol, Ambiguous) {
   auto T = Annotations(R"cpp(
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -374,6 +374,18 @@
   unsigned WordOffset = Word.data() - Code.data();
   SourceLocation WordStart = SM.getComposedLoc(File, WordOffset);
 
+  // Attempt to determine the kind of token that contains the word,
+  // and bail if it's a string literal. Note that we cannot always
+  // determine the token kind (e.g. comments, for which we do want
+  // to activate, are not retained by TokenBuffer).
+  for (syntax::Token T :
+   syntax::spelledTokensTouching(WordStart, AST.getTokens())) {
+if (T.range(AST.getSourceManager()).touches(WordOffset + Word.size())) {
+  if (isStringLiteral(T.kind()))
+return {};
+}
+  }
+
   // Do not consider tokens that survived preprocessing.
   // We are erring on the safe side here, as a user may expect to get
   // accurate (as opposed to textual-heuristic) results for such tokens.


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -628,7 +628,8 @@
 // Comment mentioning M^yClass
   )cpp",
   R"cpp(// String
-struct [[MyClass]] {};
+struct MyClass {};
+// Not triggered for string literal tokens.
 const char* s = "String literal mentioning M^yClass";
   )cpp",
   R"cpp(// Ifdef'ed out code
@@ -680,7 +681,7 @@
   EXPECT_EQ(Results[0].PreferredDeclaration.range, *WantDecl) << Test;
 }
   }
-}
+} // namespace
 
 TEST(LocateSymbol, Ambiguous) {
   auto T = Annotations(R"cpp(
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -374,6 +374,18 @@
   unsigned WordOffset = Word.data() - Code.data();
   SourceLocation WordStart = SM.getComposedLoc(File, WordOffset);
 
+  // Attempt to determine the kind of token that contains the word,
+  // and bail if it's a string literal. Note that we cannot always
+  // determine the token kind (e.g. comments, for which we do want
+  // to activate, are not retained by TokenBuffer).
+  for (syntax::Token T :
+   syntax::spelledTokensTouching(WordStart, AST.getTokens())) {
+if (T.range(AST.getSourceManager()).touches(WordOffset + Word.size())) {
+  if (isStringLiteral(T.kind()))
+return {};
+}
+  }
+
   // Do not consider tokens that survived preprocessing.
   // We are erring on the safe side here, as a user may expect to get
   // accurate (as opposed to textual-heuristic) results for such tokens.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76098: [clangd] Do not trigger go-to-def textual fallback inside string literals

[Nathan Ridge via Phabricator via cfe-commits]

nridge marked an inline comment as done.
nridge added inline comments.



Comment at: clang-tools-extra/clangd/XRefs.cpp:381
+  // to activate, are not retained by TokenBuffer).
+  for (syntax::Token T : syntax::spelledTokensTouching(Loc, AST.getTokens())) {
+if (T.range(AST.getSourceManager()).touches(WordOffset + Word.size())) {

Whoops, meant to use `WordStart` rather than `Loc` here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76098/new/

https://reviews.llvm.org/D76098



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] b89202e - [clangd] Do not trigger go-to-def textual fallback inside string literals

[Nathan Ridge via cfe-commits]

Author: Nathan Ridge
Date: 2020-03-19T17:24:45-04:00
New Revision: b89202e842acda4d6519cb45c98128827df84a2f

URL: 
https://github.com/llvm/llvm-project/commit/b89202e842acda4d6519cb45c98128827df84a2f
DIFF: 
https://github.com/llvm/llvm-project/commit/b89202e842acda4d6519cb45c98128827df84a2f.diff

LOG: [clangd] Do not trigger go-to-def textual fallback inside string literals

Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, 
cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clangd/XRefs.cpp
clang-tools-extra/clangd/unittests/XRefsTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/XRefs.cpp 
b/clang-tools-extra/clangd/XRefs.cpp
index acf9f6df8281..7d55a372905c 100644
--- a/clang-tools-extra/clangd/XRefs.cpp
+++ b/clang-tools-extra/clangd/XRefs.cpp
@@ -374,6 +374,18 @@ locateSymbolNamedTextuallyAt(ParsedAST , const 
SymbolIndex *Index,
   unsigned WordOffset = Word.data() - Code.data();
   SourceLocation WordStart = SM.getComposedLoc(File, WordOffset);
 
+  // Attempt to determine the kind of token that contains the word,
+  // and bail if it's a string literal. Note that we cannot always
+  // determine the token kind (e.g. comments, for which we do want
+  // to activate, are not retained by TokenBuffer).
+  for (syntax::Token T :
+   syntax::spelledTokensTouching(WordStart, AST.getTokens())) {
+if (T.range(AST.getSourceManager()).touches(WordOffset + Word.size())) {
+  if (isStringLiteral(T.kind()))
+return {};
+}
+  }
+
   // Do not consider tokens that survived preprocessing.
   // We are erring on the safe side here, as a user may expect to get
   // accurate (as opposed to textual-heuristic) results for such tokens.

diff  --git a/clang-tools-extra/clangd/unittests/XRefsTests.cpp 
b/clang-tools-extra/clangd/unittests/XRefsTests.cpp
index 32a89df424e4..fc36dfa42d7f 100644
--- a/clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ b/clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -644,7 +644,8 @@ TEST(LocateSymbol, Textual) {
 // Comment mentioning M^yClass
   )cpp",
   R"cpp(// String
-struct [[MyClass]] {};
+struct MyClass {};
+// Not triggered for string literal tokens.
 const char* s = "String literal mentioning M^yClass";
   )cpp",
   R"cpp(// Ifdef'ed out code
@@ -696,7 +697,7 @@ TEST(LocateSymbol, Textual) {
   EXPECT_EQ(Results[0].PreferredDeclaration.range, *WantDecl) << Test;
 }
   }
-}
+} // namespace
 
 TEST(LocateSymbol, Ambiguous) {
   auto T = Annotations(R"cpp(



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76392: [AST] Make Expr::setDependence protected and remove add/removeDependence. NFC

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb4f02d89e5d8: [AST] Make Expr::setDependence protected and 
remove add/removeDependence. NFC (authored by sammccall).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76392/new/

https://reviews.llvm.org/D76392

Files:
  clang/include/clang/AST/Expr.h
  clang/lib/AST/ComputeDependence.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConcepts.cpp
  clang/lib/Sema/SemaOverload.cpp

Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -12720,7 +12720,7 @@
   // base classes.
   CallExpr *CE = CallExpr::Create(Context, Fn, Args, Context.DependentTy,
   VK_RValue, RParenLoc);
-  CE->addDependence(ExprDependence::TypeValueInstantiation);
+  CE->markDependentForPostponedNameLookup();
   *Result = CE;
   return true;
 }
Index: clang/lib/AST/ExprConcepts.cpp
===
--- clang/lib/AST/ExprConcepts.cpp
+++ clang/lib/AST/ExprConcepts.cpp
@@ -175,13 +175,13 @@
   RequiresExprBits.IsSatisfied |= Dependent;
   // FIXME: move the computing dependency logic to ComputeDependence.h
   if (ContainsUnexpandedParameterPack)
-addDependence(ExprDependence::UnexpandedPack);
+setDependence(getDependence() | ExprDependence::UnexpandedPack);
   // FIXME: this is incorrect for cases where we have a non-dependent
   // requirement, but its parameters are instantiation-dependent. RequiresExpr
   // should be instantiation-dependent if it has instantiation-dependent
   // parameters.
   if (Dependent)
-addDependence(ExprDependence::ValueInstantiation);
+setDependence(getDependence() | ExprDependence::ValueInstantiation);
 }
 
 RequiresExpr::RequiresExpr(ASTContext , EmptyShell Empty,
Index: clang/lib/AST/Expr.cpp
===
--- clang/lib/AST/Expr.cpp
+++ clang/lib/AST/Expr.cpp
@@ -1497,28 +1497,15 @@
   MemberExpr *E = new (Mem) MemberExpr(Base, IsArrow, OperatorLoc, MemberDecl,
NameInfo, T, VK, OK, NOUR);
 
-  if (isa(MemberDecl)) {
-DeclContext *DC = MemberDecl->getDeclContext();
-// dyn_cast_or_null is used to handle objC variables which do not
-// have a declaration context.
-CXXRecordDecl *RD = dyn_cast_or_null(DC);
-if (RD && RD->isDependentContext() && RD->isCurrentInstantiation(DC)) {
-  if (E->isTypeDependent() && !T->isDependentType())
-E->removeDependence(ExprDependence::Type);
-}
-// Bitfield with value-dependent width is type-dependent.
-FieldDecl *FD = dyn_cast(MemberDecl);
-if (FD && FD->isBitField() && FD->getBitWidth()->isValueDependent())
-  E->addDependence(ExprDependence::Type);
-  }
-
+  // FIXME: remove remaining dependence computation to computeDependence().
+  auto Deps = E->getDependence();
   if (HasQualOrFound) {
 // FIXME: Wrong. We should be looking at the member declaration we found.
 if (QualifierLoc && QualifierLoc.getNestedNameSpecifier()->isDependent())
-  E->addDependence(ExprDependence::TypeValueInstantiation);
+  Deps |= ExprDependence::TypeValueInstantiation;
 else if (QualifierLoc &&
  QualifierLoc.getNestedNameSpecifier()->isInstantiationDependent())
-  E->addDependence(ExprDependence::Instantiation);
+  Deps |= ExprDependence::Instantiation;
 
 E->MemberExprBits.HasQualifierOrFoundDecl = true;
 
@@ -1532,16 +1519,17 @@
   TemplateArgs || TemplateKWLoc.isValid();
 
   if (TemplateArgs) {
-auto Deps = TemplateArgumentDependence::None;
+auto TemplateArgDeps = TemplateArgumentDependence::None;
 E->getTrailingObjects()->initializeFrom(
 TemplateKWLoc, *TemplateArgs,
-E->getTrailingObjects(), Deps);
-if (Deps & TemplateArgumentDependence::Instantiation)
-  E->addDependence(ExprDependence::Instantiation);
+E->getTrailingObjects(), TemplateArgDeps);
+if (TemplateArgDeps & TemplateArgumentDependence::Instantiation)
+  Deps |= ExprDependence::Instantiation;
   } else if (TemplateKWLoc.isValid()) {
 E->getTrailingObjects()->initializeFrom(
 TemplateKWLoc);
   }
+  E->setDependence(Deps);
 
   return E;
 }
Index: clang/lib/AST/ComputeDependence.cpp
===
--- clang/lib/AST/ComputeDependence.cpp
+++ clang/lib/AST/ComputeDependence.cpp
@@ -482,7 +482,25 @@
 }
 
 ExprDependence clang::computeDependence(MemberExpr *E) {
-  return E->getBase()->getDependence();
+  auto *MemberDecl = E->getMemberDecl();
+  auto D = E->getBase()->getDependence();
+  if (FieldDecl *FD = dyn_cast(MemberDecl)) {
+DeclContext *DC = MemberDecl->getDeclContext();
+// dyn_cast_or_null is used to handle objC 

[PATCH] D76455: [NFC] Refactor handling of Xarch option

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added a reviewer: tra.

Extract common code to a function. To prepare for adding an option for CUDA/HIP 
host and device only option.


https://reviews.llvm.org/D76455

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/HIP.cpp

Index: clang/lib/Driver/ToolChains/HIP.cpp
===
--- clang/lib/Driver/ToolChains/HIP.cpp
+++ clang/lib/Driver/ToolChains/HIP.cpp
@@ -382,31 +382,7 @@
   // Skip this argument unless the architecture matches BoundArch.
   if (BoundArch.empty() || A->getValue(0) != BoundArch)
 continue;
-
-  unsigned Index = Args.getBaseArgs().MakeIndex(A->getValue(1));
-  unsigned Prev = Index;
-  std::unique_ptr XarchArg(Opts.ParseOneArg(Args, Index));
-
-  // If the argument parsing failed or more than one argument was
-  // consumed, the -Xarch_ argument's parameter tried to consume
-  // extra arguments. Emit an error and ignore.
-  //
-  // We also want to disallow any options which would alter the
-  // driver behavior; that isn't going to work in our model. We
-  // use isDriverOption() as an approximation, although things
-  // like -O4 are going to slip through.
-  if (!XarchArg || Index > Prev + 1) {
-getDriver().Diag(diag::err_drv_invalid_Xarch_argument_with_args)
-<< A->getAsString(Args);
-continue;
-  } else if (XarchArg->getOption().hasFlag(options::DriverOption)) {
-getDriver().Diag(diag::err_drv_invalid_Xarch_argument_isdriver)
-<< A->getAsString(Args);
-continue;
-  }
-  XarchArg->setBaseArg(A);
-  A = XarchArg.release();
-  DAL->AddSynthesizedArg(A);
+  TranslateXarchArgs(Args, A, DAL);
 }
 DAL->append(A);
   }
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2132,32 +2132,7 @@
 continue;
 
   Arg *OriginalArg = A;
-  unsigned Index = Args.getBaseArgs().MakeIndex(A->getValue(1));
-  unsigned Prev = Index;
-  std::unique_ptr XarchArg(Opts.ParseOneArg(Args, Index));
-
-  // If the argument parsing failed or more than one argument was
-  // consumed, the -Xarch_ argument's parameter tried to consume
-  // extra arguments. Emit an error and ignore.
-  //
-  // We also want to disallow any options which would alter the
-  // driver behavior; that isn't going to work in our model. We
-  // use isDriverOption() as an approximation, although things
-  // like -O4 are going to slip through.
-  if (!XarchArg || Index > Prev + 1) {
-getDriver().Diag(diag::err_drv_invalid_Xarch_argument_with_args)
-<< A->getAsString(Args);
-continue;
-  } else if (XarchArg->getOption().hasFlag(options::DriverOption)) {
-getDriver().Diag(diag::err_drv_invalid_Xarch_argument_isdriver)
-<< A->getAsString(Args);
-continue;
-  }
-
-  XarchArg->setBaseArg(A);
-
-  A = XarchArg.release();
-  DAL->AddSynthesizedArg(A);
+  TranslateXarchArgs(Args, A, DAL);
 
   // Linker input arguments require custom handling. The problem is that we
   // have already constructed the phase actions, so we can not treat them as
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -804,31 +804,7 @@
   // Skip this argument unless the architecture matches BoundArch
   if (BoundArch.empty() || A->getValue(0) != BoundArch)
 continue;
-
-  unsigned Index = Args.getBaseArgs().MakeIndex(A->getValue(1));
-  unsigned Prev = Index;
-  std::unique_ptr XarchArg(Opts.ParseOneArg(Args, Index));
-
-  // If the argument parsing failed or more than one argument was
-  // consumed, the -Xarch_ argument's parameter tried to consume
-  // extra arguments. Emit an error and ignore.
-  //
-  // We also want to disallow any options which would alter the
-  // driver behavior; that isn't going to work in our model. We
-  // use isDriverOption() as an approximation, although things
-  // like -O4 are going to slip through.
-  if (!XarchArg || Index > Prev + 1) {
-getDriver().Diag(diag::err_drv_invalid_Xarch_argument_with_args)
-<< A->getAsString(Args);
-continue;
-  } else if (XarchArg->getOption().hasFlag(options::DriverOption)) {
-getDriver().Diag(diag::err_drv_invalid_Xarch_argument_isdriver)
-<< A->getAsString(Args);
-continue;
-  }
-  XarchArg->setBaseArg(A);
-  A = XarchArg.release();
-  

[PATCH] D76447: Apply ConstantEvaluated evaluation contexts to more manifestly constant evaluated scopes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:16793-16797
+  if (isManifestlyEvaluatedVar(*this, D)) {
+using ExpressionKind = ExpressionEvaluationContextRecord::ExpressionKind;
+
+PushExpressionEvaluationContext(
+ExpressionEvaluationContext::ConstantEvaluated, D, 
ExpressionKind::EK_ConstexprVarInit);

We can't implement the checks for manifestly constant-evaluated initializers 
this way in general. Per [expr.const]/14, we need to treat the initializer as 
manifestly constant-evaluated if it's "the initializer of a variable that is 
usable in constant expressions or has constant initialization". We can't test 
either of those conditions in general until we know what the initializer is, 
because they can both depend on whether evaluation of the initializer succeeds. 
(This approach works for the case of `constexpr` variables, which are always 
usable in constant expressions, but not any of the other cases, and the 
approach we'll need for the other cases will also handle `constexpr` variables. 
There is a very modest benefit to special-casing `constexpr` variable 
initializers regardless -- we can avoid forming and then pruning out nested 
`ConstantExpr` nodes for immediate invocations inside the initializer -- but I 
think it's probably not worth the added complexity.)

To address the general problem, we should handle this in 
`CheckCompleteVariableDeclaration`, which is where we evaluate the initializer 
and generally determine whether the variable has constant initialization and / 
or is usable in constant expressions. Probably the cleanest approach -- and 
certainly the one I'd been intending to pursue -- would be to wrap the 
initializer with a `ConstantExpr` there in the relevant cases, and allow the 
usual handling of nested immediate invocations to prune out any `ConstantExpr`s 
nested within the initializer representing inner calls to `consteval` 
functions. (I think I've mentioned elsewhere that I would like to remove the 
"evaluated value" storage on `VarDecl` in favor of using `ConstantExpr` for 
this purpose.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76447/new/

https://reviews.llvm.org/D76447



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram updated this revision to Diff 251469.
tmsriram marked 4 inline comments as done.
tmsriram added a comment.

Address reviewer comments.

- reword comment
- rewrite test to use -emit-llvm


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/unique-internal-funcnames.c
  clang/test/Driver/funique-internal-funcnames.c

Index: clang/test/Driver/funique-internal-funcnames.c
===
--- /dev/null
+++ clang/test/Driver/funique-internal-funcnames.c
@@ -0,0 +1,4 @@
+// RUN: %clang -### -funique-internal-funcnames %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -funique-internal-funcnames -fno-unique-internal-funcnames %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// CHECK-OPT: "-funique-internal-funcnames"
+// CHECK-NOOPT-NOT: {{-funique-internal-funcnames}}
Index: clang/test/CodeGen/unique-internal-funcnames.c
===
--- /dev/null
+++ clang/test/CodeGen/unique-internal-funcnames.c
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple x86_64 -S -emit-llvm -o - < %s | FileCheck %s --check-prefix=PLAIN
+// RUN: %clang_cc1 -triple x86_64 -S -emit-llvm -funique-internal-funcnames -o - < %s | FileCheck %s --check-prefix=UNIQUE
+
+static int foo() {
+  return 0;
+}
+
+int (*bar())() {
+  return foo;
+}
+
+// PLAIN: @foo()
+// UNIQUE-NOT: @foo()
+// UNIQUE: @foo.{{[0-9a-f]+}}()
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -958,6 +958,7 @@
   Opts.StackSizeSection = Args.hasArg(OPT_fstack_size_section);
   Opts.UniqueSectionNames = !Args.hasArg(OPT_fno_unique_section_names);
 
+  Opts.UniqueInternalFuncNames = Args.hasArg(OPT_funique_internal_funcnames);
   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
 
   Opts.NoUseJumpTables = Args.hasArg(OPT_fno_jump_tables);
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1124,6 +1124,23 @@
   const auto *ND = cast(GD.getDecl());
   std::string MangledName = getMangledNameImpl(*this, GD, ND);
 
+  // With option -funique-internal-funcnames, functions with internal linkage
+  // should get unique names.  Use the hash of module name to get a unique
+  // identifier as this is a best-effort solution.
+  if (getCodeGenOpts().UniqueInternalFuncNames &&
+  dyn_cast(GD.getDecl()) &&
+  getFunctionLinkage(GD) == llvm::GlobalValue::InternalLinkage &&
+  !getModule().getSourceFileName().empty()) {
+llvm::MD5 Md5;
+Md5.update(getModule().getSourceFileName());
+llvm::MD5::MD5Result R;
+Md5.final(R);
+SmallString<32> Str;
+llvm::MD5::stringifyResult(R, Str);
+std::string UniqueSuffix = ("." + Str).str();
+MangledName += UniqueSuffix;
+  }
+
   // Ensure either we have different ABIs between host and device compilations,
   // says host compilation following MSVC ABI but device compilation follows
   // Itanium C++ ABI or, if they follow the same ABI, kernel names after
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4222,6 +4222,8 @@
 options::OPT_fno_function_sections,
 options::OPT_fdata_sections,
 options::OPT_fno_data_sections,
+options::OPT_funique_internal_funcnames,
+options::OPT_fno_unique_internal_funcnames,
 options::OPT_funique_section_names,
 options::OPT_fno_unique_section_names,
 options::OPT_mrestrict_it,
@@ -4819,6 +4821,10 @@
 options::OPT_fno_unique_section_names, true))
 CmdArgs.push_back("-fno-unique-section-names");
 
+  if (Args.hasFlag(options::OPT_funique_internal_funcnames,
+   options::OPT_fno_unique_internal_funcnames, false))
+CmdArgs.push_back("-funique-internal-funcnames");
+
   Args.AddLastArg(CmdArgs, options::OPT_finstrument_functions,
   options::OPT_finstrument_functions_after_inlining,
   options::OPT_finstrument_function_entry_bare);
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1971,6 +1971,12 @@
 def fno_unique_section_names : Flag <["-"], "fno-unique-section-names">,
   Group, Flags<[CC1Option]>;
 
+def funique_internal_funcnames 

[PATCH] D76385: Allow remapping Clang module include paths

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:2487
+  // Return a StringRef to the remapped Path.
+  auto RemapPath = [&](std::string Path) -> std::string {
+Path = remapDIPath(Path);

`&` -> `` 

We should try to explicitly capture what we use, this will avoid potential bugs 
where we accidentally modify something we did not mean to capture later on when 
modifying the code.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76385/new/

https://reviews.llvm.org/D76385



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76432: [clangd] Add a tweak for adding "using" statement.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

This seems really well-thought-out.
I'm being (even) more verbose than usual about the interesting AST details. 
Please do push back/defer fixing anything that adds a lot of complexity and 
doesn't seem important.




Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:20
+
+// Tweak for removing full namespace qualifier under cursor on function calls
+// and types and adding "using" statement instead.

function calls is obsolete I think, I'd just call these references or 
DeclRefExpr



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:22
+// and types and adding "using" statement instead.
+class AddUsing : public Tweak {
+public:

You could put some general comments about the scope/choices here (applicable 
only to namespaces, insertion strategy)



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:22
+// and types and adding "using" statement instead.
+class AddUsing : public Tweak {
+public:

sammccall wrote:
> You could put some general comments about the scope/choices here (applicable 
> only to namespaces, insertion strategy)
> Removing qualifier from other instances of the same type/call.

I think this is valuable enough to be worth calling out in the top-level 
comment as not-yet-done.
The other extensions you mention seem like we might never get around to them 
and it'd be fine.



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:34
+// True iff "using" already exists and we should not add it.
+bool IdenticalUsingFound = false;
+// Location to insert the "using" statement.

is this redundant with Loc.isValid()?

If so, I'd either just use Loc (with a comment), or use 
optional with a comment, to emphasize the relationship.



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:37
+SourceLocation Loc;
+// Extra suffix to place after the "using" statement. Depending on what the
+// insertion point is anchored to, we may need one or more \n to ensure

can we get away with always inserting \n and relying on clang-format to clean 
it up?



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:44
+  // SourceLocation if the "using" statement already exists.
+  llvm::Expected
+  findInsertionPoint(const Selection );

this doesn't use any state - make it static or a free function?



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:48
+  // The qualifier to remove. Set by prepare().
+  NestedNameSpecifierLoc NNSL;
+  // The name following NNSL. Set by prepare().

nit: I quite like the abbreviated names for locals but this deserves a real 
name like Qualifier or QualifierToRemove.



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:54
+
+std::string AddUsing::title() const {
+  return std::string(

Can we make this dynamic? The more clearly we communicate what is targeted, the 
more confidence the user will have to use it.

`title()` may only be called after a successful prepare(), so we can use the 
prepared state.

Maybe something like `Add using-declaration for Bar, and remove qualifier`?



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:56
+  return std::string(
+  llvm::formatv("Add using statement and remove full qualifier."));
+}

nit: not actually a statement :-(

If "using-declaration" is overly laywerly (and easily confused with 
using-directive), then maybe we should just spell it out: `Add "using foo::Bar" 
...`



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:68
+auto Loc = D->getUsingLoc();
+if (Loc.isInvalid() || Loc.isMacroID() ||
+SM.getFileID(Loc) != SM.getMainFileID()) {

no need for the first two conditions, getFileID will give you an invalid fileid 
and a macro fileid respectively



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:71
+  return true;
+}
+if (D->getDeclContext()->Encloses(SelectionDeclContext)) {

nit: we conventionally leave out the {} on one-line if bodies etc.



Comment at: clang-tools-extra/clangd/refactor/tweaks/AddUsing.cpp:72
+}
+if (D->getDeclContext()->Encloses(SelectionDeclContext)) {
+  Results.push_back(D);

This check is sufficient for correctness, but we're still going to traverse all 
the parts of the AST that can't pass this check.

I think you can override TraverseDecl. If the Decl is a DeclContext and it 
doesn't enclose the selectiondc, then return (pruning that subtree). Otherwise 
call RecursiveASTVisitor::TraverseDecl and continue as before.

(I think you still want this check though - pruning 

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I guess my initial reaction is that it is disappointing that downstream 
consumers can't cope with non-unique symbol names (What is the point of having 
internal linkage if we can't rely on it?), but given @mtrofin's input about 
AFDO, this seems like it may be a practical solution. I can think of at least 
two other cases where I have wanted similar functionality, the first being 
unique names for CodeView types in anonymous namespaces, the second being Jumbo 
support, producing one object from two .cpp source inputs.

To handle the case for type identifiers, we came up with this solution:
https://github.com/llvm/llvm-project/blob/master/clang/lib/AST/MicrosoftMangle.cpp#L401
Your solution is pretty similar.

In D73307#1839829 , @MaskRay wrote:

> I haven't followed Propeller development, but hope someone with profile 
> experience can confirm InternalLinkage is the only linkage we need to care 
> about (otherwise the option will be a misnomer if we ever extend it) and 
> check whether this feature is useful on its own.


There is one other "local" linkage type, `private` linkage, which I believe 
corresponds with temporary assembler labels (.L*) that don't survive into the 
object file symbol table. I think the main use case for private globals is to 
save on symbol table size, so if the user passes this flag, it seems reasonable 
to upgrade the linkage to internal, and assign a unique name.

There is also the case of unnamed globals, which I think are private. I don't 
think clang ever generates these, so they are not very interesting.

I grepped the clang/test subdirectory for 'define.*private', and it seems there 
are no tests for private functions, so I doubt clang ever emits them.

---

At a higher level, should this just be an IR pass that clang adds into the 
pipeline when the flag is set? It should be safe to rename internal functions 
and give private functions internal linkage. It would be less invasive to clang 
and have better separation of concerns. As written, this is based on the source 
filename on the module, which is accessible from IR. The only reason I can 
think of against this is that the debug info might refer to the function 
linkage name, but maybe that is calculated later during codegen.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1062
 
   return std::string(Out.str());
 }

We seem to be defeating NRVO with our "clever" small string type. :(



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1125
   const auto *ND = cast(GD.getDecl());
   std::string MangledName = getMangledNameImpl(*this, GD, ND);
 

There are several other callers of getMangledNameImpl. Should they also use 
this suffix? They mostly have to do with function multiversioning. Those seem 
like they could be internal and need this treatment.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1131
+  if (getCodeGenOpts().UniqueInternalFuncNames &&
+  dyn_cast(GD.getDecl()) &&
+  getFunctionLinkage(GD) == llvm::GlobalValue::InternalLinkage &&

`isa` would be more idiomatic than testing `dyn_cast` results for truth.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1135
+llvm::MD5 Md5;
+Md5.update(getModule().getSourceFileName());
+llvm::MD5::MD5Result R;

davidxl wrote:
> Source filenames are not guaranteed to be unique, or it does contain the path 
> as well?
It appears to contain the path as the compiler receives it on the command line. 
However, it is possible to design a build where this string is not unique:
```
cd foo
clang -c name_conflict.c 
cd ../bar
clang -c name_conflict.c
clang foo/name_conflict.o bar/name_conflict.o
```

I don't think we should try to handle this case, but we should document the 
limitation somewhere. Some build systems do operate changing the working 
directory as they go.

Can you add some to the clang/docs/UsersManual.rst file? I'd expect it to show 
up here:
https://clang.llvm.org/docs/UsersManual.html#command-line-options

You can elaborate that the unique names are calculated using the source path 
passed to the compiler, and in a build system where that is not unique, the 
function names may not be unique.

---

I have also used this construct in the past for building single-file ABI 
compatibility test cases:

```
// foo.cpp
#ifdef PART1
// ...
#elif defined(PART2)
// ...
#endif

$ cc -c foo.cpp -DPART1
$ cc -c foo.cpp -DPART2
```



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1139
+SmallString<32> Str;
+llvm::MD5::stringifyResult(R, Str);
+std::string UniqueSuffix = ("." + Str).str();

I think it would be preferable to calculate the source filename MD5 hash once, 
when CodeGenModule is constructed, stringify it, and then use that every time 
we mangle a name.



Comment at: 

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added inline comments.



Comment at: clang/test/CodeGen/unique-internal-funcnames.c:16
+// UNIQUE-NOT: foo:
+// UNIQUE: foo.{{[0-9a-f]+}}:

lebedev.ri wrote:
> What does `getModule().getSourceFileName()` contain?
> The full path to the source file, or just the source file basename?
> If latter, maybe check the full name?
It contains the full path. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] b4f02d8 - [AST] Make Expr::setDependence protected and remove add/removeDependence. NFC

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-03-19T21:54:40+01:00
New Revision: b4f02d89e5d8d2e3b85abced3964c937b693494c

URL: 
https://github.com/llvm/llvm-project/commit/b4f02d89e5d8d2e3b85abced3964c937b693494c
DIFF: 
https://github.com/llvm/llvm-project/commit/b4f02d89e5d8d2e3b85abced3964c937b693494c.diff

LOG: [AST] Make Expr::setDependence protected and remove add/removeDependence. 
NFC

Summary:
The expected pattern is for subclasses to initialize through
computeDependence, which needs only setDependence.
The few places that still use addDependence can be simulated with get+set.

Reviewers: hokein

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/AST/Expr.h
clang/lib/AST/ComputeDependence.cpp
clang/lib/AST/Expr.cpp
clang/lib/AST/ExprConcepts.cpp
clang/lib/Sema/SemaOverload.cpp

Removed: 




diff  --git a/clang/include/clang/AST/Expr.h b/clang/include/clang/AST/Expr.h
index 0a136a737658..78c344b59d05 100644
--- a/clang/include/clang/AST/Expr.h
+++ b/clang/include/clang/AST/Expr.h
@@ -130,6 +130,14 @@ class Expr : public ValueStmt {
   /// Construct an empty expression.
   explicit Expr(StmtClass SC, EmptyShell) : ValueStmt(SC) { }
 
+  /// Each concrete expr subclass is expected to compute its dependence and 
call
+  /// this in the constructor.
+  void setDependence(ExprDependence Deps) {
+ExprBits.Dependent = static_cast(Deps);
+  }
+  friend class ASTImporter; // Sets dependence dircetly.
+  friend class ASTStmtReader; // Sets dependence dircetly.
+
 public:
   QualType getType() const { return TR; }
   void setType(QualType t) {
@@ -149,18 +157,6 @@ class Expr : public ValueStmt {
 return static_cast(ExprBits.Dependent);
   }
 
-  /// Each concrete expr subclass is expected to compute its dependence and 
call
-  /// this in the constructor.
-  void setDependence(ExprDependence Deps) {
-ExprBits.Dependent = static_cast(Deps);
-  }
-  void addDependence(ExprDependence Deps) {
-ExprBits.Dependent |= static_cast(Deps);
-  }
-  void removeDependence(ExprDependence Deps) {
-ExprBits.Dependent &= ~static_cast(Deps);
-  }
-
   /// isValueDependent - Determines whether this expression is
   /// value-dependent (C++ [temp.dep.constexpr]). For example, the
   /// array bound of "Chars" in the following example is
@@ -2773,6 +2769,12 @@ class CallExpr : public Expr {
   /// a non-value-dependent constant parameter evaluating as false.
   bool isBuiltinAssumeFalse(const ASTContext ) const;
 
+  /// Used by Sema to implement MSVC-compatible delayed name lookup.
+  /// (Usually Exprs themselves should set dependence).
+  void markDependentForPostponedNameLookup() {
+setDependence(getDependence() | ExprDependence::TypeValueInstantiation);
+  }
+
   bool isCallToStdMove() const {
 const FunctionDecl *FD = getDirectCallee();
 return getNumArgs() == 1 && FD && FD->isInStdNamespace() &&
@@ -4384,7 +4386,7 @@ class InitListExpr : public Expr {
 InitExprs[Init] = expr;
 
 if (expr)
-  addDependence(expr->getDependence());
+  setDependence(getDependence() | expr->getDependence());
   }
 
   /// Reserve space for some number of initializers.

diff  --git a/clang/lib/AST/ComputeDependence.cpp 
b/clang/lib/AST/ComputeDependence.cpp
index 348fae1cfb19..20b2837d9d33 100644
--- a/clang/lib/AST/ComputeDependence.cpp
+++ b/clang/lib/AST/ComputeDependence.cpp
@@ -482,7 +482,25 @@ ExprDependence clang::computeDependence(OffsetOfExpr *E) {
 }
 
 ExprDependence clang::computeDependence(MemberExpr *E) {
-  return E->getBase()->getDependence();
+  auto *MemberDecl = E->getMemberDecl();
+  auto D = E->getBase()->getDependence();
+  if (FieldDecl *FD = dyn_cast(MemberDecl)) {
+DeclContext *DC = MemberDecl->getDeclContext();
+// dyn_cast_or_null is used to handle objC variables which do not
+// have a declaration context.
+CXXRecordDecl *RD = dyn_cast_or_null(DC);
+if (RD && RD->isDependentContext() && RD->isCurrentInstantiation(DC)) {
+  if (!E->getType()->isDependentType())
+D &= ~ExprDependence::Type;
+}
+
+// Bitfield with value-dependent width is type-dependent.
+if (FD && FD->isBitField() && FD->getBitWidth()->isValueDependent()) {
+  D |= ExprDependence::Type;
+}
+  }
+  // FIXME: move remaining dependence computation from MemberExpr::Create()
+  return D;
 }
 
 ExprDependence clang::computeDependence(InitListExpr *E) {

diff  --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 9b0cc2b69dd4..d0813436548f 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -1497,28 +1497,15 @@ MemberExpr *MemberExpr::Create(
   MemberExpr *E = new (Mem) MemberExpr(Base, IsArrow, OperatorLoc, MemberDecl,
NameInfo, T, VK, OK, NOUR);
 
-  if (isa(MemberDecl)) {
-DeclContext *DC = 

[PATCH] D66094: [CodeGen] Emit destructor calls for non-trivial C structs returned by function calls and loaded from volatile objects

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak updated this revision to Diff 251463.
ahatanak marked an inline comment as done.
ahatanak added a comment.

Teach `Expr::isConstantInitializer` that `ExprWithCleanups` can be a constant.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66094/new/

https://reviews.llvm.org/D66094

Files:
  clang/lib/AST/Expr.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGCall.h
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/CodeGen/CGVTables.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CodeGenObjC/arc.m
  clang/test/CodeGenObjC/strong-in-c-struct.m

Index: clang/test/CodeGenObjC/strong-in-c-struct.m
===
--- clang/test/CodeGenObjC/strong-in-c-struct.m
+++ clang/test/CodeGenObjC/strong-in-c-struct.m
@@ -89,6 +89,13 @@
 void calleeStrongSmall(StrongSmall);
 void func(Strong *);
 
+@interface C
+- (StrongSmall)getStrongSmall;
++ (StrongSmall)getStrongSmallClass;
+@end
+
+id g0;
+
 // CHECK: %[[STRUCT_STRONGOUTER:.*]] = type { %[[STRUCT_STRONG:.*]], i8*, double }
 // CHECK: %[[STRUCT_STRONG]] = type { %[[STRUCT_TRIVIAL:.*]], i8* }
 // CHECK: %[[STRUCT_TRIVIAL]] = type { [4 x i32] }
@@ -476,6 +483,18 @@
   getStrongSmall();
 }
 
+// CHECK: define void @test_destructor_ignored_result2(%{{.*}}* %[[C:.*]])
+// CHECK: %[[TMP:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
+// CHECK: %[[CALL:.*]] = call [2 x i64]{{.*}}@objc_msgSend
+// CHECK: %[[V5:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[TMP]] to [2 x i64]*
+// CHECK: store [2 x i64] %[[CALL]], [2 x i64]* %[[V5]], align 8
+// CHECK: %[[V6:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[TMP]] to i8**
+// CHECK: call void @__destructor_8_s8(i8** %[[V6]])
+
+void test_destructor_ignored_result2(C *c) {
+  [c getStrongSmall];
+}
+
 // CHECK: define void @test_copy_constructor_StrongBlock(
 // CHECK: call void @__copy_constructor_8_8_sb0(
 // CHECK: call void @__destructor_8_sb0(
@@ -520,7 +539,9 @@
 
 // CHECK: define void @test_copy_constructor_StrongVolatile0(
 // CHECK: call void @__copy_constructor_8_8_t0w4_sv8(
+// CHECK-NOT: call
 // CHECK: call void @__destructor_8_sv8(
+// CHECK-NOT: call
 
 // CHECK: define linkonce_odr hidden void @__copy_constructor_8_8_t0w4_sv8(
 // CHECK: %[[V8:.*]] = load volatile i8*, i8** %{{.*}}, align 8
@@ -808,4 +829,62 @@
   func(0);
 }
 
+// CHECK: define void @test_member_access(
+// CHECK: %[[TMP:.*]] = alloca %[[STRUCT_STRONGSMALL]],
+// CHECK: %[[V3:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[TMP]] to i8**
+// CHECK: call void @__destructor_8_s8(i8** %[[V3]])
+// CHECK: call void @func(
+
+void test_member_access(void) {
+  g0 = getStrongSmall().f1;
+  func(0);
+}
+
+// CHECK: define void @test_member_access2(%{{.*}}* %[[C:.*]])
+// CHECK: %[[COERCE:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
+// CHECK: %[[V8:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[COERCE]] to i8**
+// CHECK: call void @__destructor_8_s8(i8** %[[V8]])
+// CHECK: call void @func(
+
+void test_member_access2(C *c) {
+  g0 = [c getStrongSmall].f1;
+  func(0);
+}
+
+// CHECK: define void @test_member_access3(
+// CHECK: %[[COERCE:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
+// CHECK: %[[V8:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[COERCE]] to i8**
+// CHECK: call void @__destructor_8_s8(i8** %[[V8]])
+// CHECK: call void @func(
+
+void test_member_access3(void) {
+  g0 = [C getStrongSmallClass].f1;
+  func(0);
+}
+
+// CHECK: define void @test_member_access4()
+// CHECK: %[[COERCE:.*]] = alloca %[[STRUCT_STRONGSMALL]], align 8
+// CHECK: %[[V5:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[COERCE]] to i8**
+// CHECK: call void @__destructor_8_s8(i8** %[[V5]])
+// CHECK: call void @func(
+
+void test_member_access4(void) {
+  g0 = ^{ StrongSmall s; return s; }().f1;
+  func(0);
+}
+
+// CHECK: define void @test_volatile_variable_reference(
+// CHECK: %[[AGG_TMP_ENSURED:.*]] = alloca %[[STRUCT_STRONGSMALL]],
+// CHECK: %[[V1:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[AGG_TMP_ENSURED]] to i8**
+// CHECK: %[[V2:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %{{.*}} to i8**
+// CHECK: call void @__copy_constructor_8_8_tv0w32_sv8(i8** %[[V1]], i8** %[[V2]])
+// CHECK: %[[V3:.*]] = bitcast %[[STRUCT_STRONGSMALL]]* %[[AGG_TMP_ENSURED]] to i8**
+// CHECK: call void @__destructor_8_s8(i8** %[[V3]])
+// CHECK: call void @func(
+
+void test_volatile_variable_reference(volatile StrongSmall *a) {
+  (void)*a;
+  func(0);
+}
+
 #endif /* USESTRUCT */
Index: clang/test/CodeGenObjC/arc.m
===
--- clang/test/CodeGenObjC/arc.m
+++ clang/test/CodeGenObjC/arc.m
@@ -1536,12 +1536,13 @@
 
 // CHECK-LABEL: define void @test71
 void test71(void) {
-  // FIXME: It would be nice if the __destructor_8_s40 for the first call (and
-  // the following lifetime.end) came before the second call.
-  

[PATCH] D76451: [clangd] Enable textual fallback for go-to-definition on dependent names

[Nathan Ridge via Phabricator via cfe-commits]

nridge marked an inline comment as done.
nridge added inline comments.



Comment at: clang-tools-extra/clangd/XRefs.cpp:234
   ParsedAST , llvm::StringRef MainFilePath,
-  const SymbolIndex *Index) {
+  const SymbolIndex *Index, bool *IsDependentName) {
   const SourceManager  = AST.getSourceManager();

In the future, I can envision expanding this to return additional information, 
possibly the AST node itself. For now, I just started with a boolean.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76451/new/

https://reviews.llvm.org/D76451



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76452: Use LLD by default for Android.

[Dan Albert via Phabricator via cfe-commits]

danalbert created this revision.
danalbert added a reviewer: srhines.
danalbert added a project: clang.
Herald added a subscriber: cryptoad.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76452

Files:
  clang/lib/Driver/ToolChains/Linux.h
  clang/test/Driver/Inputs/basic_android_tree/arm-linux-androideabi/bin/ld.lld
  clang/test/Driver/Inputs/basic_android_tree/bin/ld.lld
  clang/test/Driver/coverage-ld.c
  clang/test/Driver/fuse-ld.c
  clang/test/Driver/sanitizer-ld.c

Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -146,7 +146,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID %s
 //
-// CHECK-ASAN-ANDROID: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-ASAN-ANDROID: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-ASAN-ANDROID-NOT: "-lc"
 // CHECK-ASAN-ANDROID-NOT: "-pie"
 // CHECK-ASAN-ANDROID-NOT: "-lpthread"
@@ -159,7 +159,7 @@
 // RUN: -static-libsan \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID-STATICLIBASAN %s
 //
-// CHECK-ASAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-ASAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-ASAN-ANDROID-STATICLIBASAN: libclang_rt.asan-arm-android.a"
 // CHECK-ASAN-ANDROID-STATICLIBASAN-NOT: "-lpthread"
 // CHECK-ASAN-ANDROID-STATICLIBASAN-NOT: "-lrt"
@@ -169,7 +169,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-ANDROID %s
 //
-// CHECK-UBSAN-ANDROID: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-UBSAN-ANDROID: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-UBSAN-ANDROID-NOT: "-lc"
 // CHECK-UBSAN-ANDROID-NOT: "-pie"
 // CHECK-UBSAN-ANDROID-NOT: "-lpthread"
@@ -182,7 +182,7 @@
 // RUN: -static-libsan \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-ANDROID-STATICLIBASAN %s
 //
-// CHECK-UBSAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-UBSAN-ANDROID-STATICLIBASAN: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-UBSAN-ANDROID-STATICLIBASAN: libclang_rt.ubsan_standalone-arm-android.a"
 // CHECK-UBSAN-ANDROID-STATICLIBASAN-NOT: "-lpthread"
 // CHECK-UBSAN-ANDROID-STATICLIBASAN-NOT: "-lrt"
@@ -193,7 +193,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID-X86 %s
 //
-// CHECK-ASAN-ANDROID-X86: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-ASAN-ANDROID-X86: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-ASAN-ANDROID-X86-NOT: "-lc"
 // CHECK-ASAN-ANDROID-X86-NOT: "-pie"
 // CHECK-ASAN-ANDROID-X86-NOT: "-lpthread"
@@ -214,7 +214,7 @@
 // RUN: -shared \
 // RUN:   | FileCheck --check-prefix=CHECK-ASAN-ANDROID-SHARED %s
 //
-// CHECK-ASAN-ANDROID-SHARED: "{{(.*[^.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-ASAN-ANDROID-SHARED: "{{(.*[^.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-ASAN-ANDROID-SHARED-NOT: "-lc"
 // CHECK-ASAN-ANDROID-SHARED: libclang_rt.asan-arm-android.so"
 // CHECK-ASAN-ANDROID-SHARED-NOT: "-lpthread"
@@ -560,7 +560,7 @@
 // RUN: -target aarch64-linux-android -fuse-ld=ld \
 // RUN: --sysroot=%S/Inputs/basic_android_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-CFI-CROSS-DSO-ANDROID %s
-// CHECK-CFI-CROSS-DSO-ANDROID: "{{.*}}ld{{(.exe)?}}"
+// CHECK-CFI-CROSS-DSO-ANDROID: "{{.*}}ld.lld{{(.exe)?}}"
 // CHECK-CFI-CROSS-DSO-ANDROID-NOT: libclang_rt.cfi
 
 // Cross-DSO CFI with diagnostics on Android links just the UBSAN runtime.
@@ -569,7 +569,7 @@
 // RUN: -target aarch64-linux-android -fuse-ld=ld \
 // RUN: --sysroot=%S/Inputs/basic_android_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-CFI-CROSS-DSO-DIAG-ANDROID %s
-// CHECK-CFI-CROSS-DSO-DIAG-ANDROID: "{{.*}}ld{{(.exe)?}}"
+// CHECK-CFI-CROSS-DSO-DIAG-ANDROID: "{{.*}}ld.lld{{(.exe)?}}"
 // CHECK-CFI-CROSS-DSO-DIAG-ANDROID: "{{[^"]*}}libclang_rt.ubsan_standalone-aarch64-android.so"
 // CHECK-CFI-CROSS-DSO-DIAG-ANDROID: "-export-dynamic-symbol=__cfi_check"
 
@@ -673,7 +673,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-SAFESTACK-ANDROID-ARM %s
 //
-// CHECK-SAFESTACK-ANDROID-ARM: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-SAFESTACK-ANDROID-ARM: "{{(.*[^-.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-SAFESTACK-ANDROID-ARM-NOT: libclang_rt.safestack
 
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o -shared 2>&1 \
@@ -681,7 +681,7 @@
 // RUN: --sysroot=%S/Inputs/basic_android_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-SAFESTACK-SHARED-ANDROID-ARM %s
 //
-// CHECK-SAFESTACK-SHARED-ANDROID-ARM: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-SAFESTACK-SHARED-ANDROID-ARM: "{{(.*[^-.0-9A-Z_a-z])?}}ld.lld{{(.exe)?}}"
 // CHECK-SAFESTACK-SHARED-ANDROID-ARM-NOT: libclang_rt.safestack
 
 // RUN: %clang 

[PATCH] D76438: ConstantExpr cached APValues if present for constant evaluation

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/lib/AST/Expr.cpp:2875
 
-  else if (auto *CE = dyn_cast(E))
-return CE->getSubExpr();
-
   return E;
 }

wchilders wrote:
> `IgnoreParensSingleStep` for some reason has been unwrapping `ConstantExpr`s. 
> This results in the constant evaluator, removing the ConstantExpr, and 
> reevaluating the expression. There are no observed downsides to removing this 
> condition, in the test suite, however, it's strange enough to note.
We sadly don't really have any good, rigorous definitions of what the various 
`Ignore*` functions do. But the general idea of `IgnoreParens` is to ignore 
syntax with no semantic effect, and `ConstantExpr` doesn't describe syntax, so 
it probably shouldn't be stepped over here. (It is ignored by `IgnoreImplicit`, 
which is generally -- mostly -- trying to ignore semantics with no syntactic 
representation, which seems appropriate. It might make sense for 
`IgnoreImpCasts` to not step over `FullExpr`s, but I expect that change would 
break some testcases.)



Comment at: clang/lib/AST/ExprConstant.cpp:7329
+  if (Result.isLValue())
+return Success(Result, E);
+}

wchilders wrote:
> This doesn't seem to be the right answer, and `ConstantExpr`s don't have 
> `LValue` `APValue`s, at least, not that are reaching this case. We had a 
> previous implementation that also, kind of punted on this issue with an 
> override in `TemporaryExprEvaluator`: 
> https://gitlab.com/lock3/clang/-/blob/9fbaeea06fc567ac472264bec2a72661a1e06c73/clang/lib/AST/ExprConstant.cpp#L9753
The base class version seems appropriate to me, even for this case. We 
eventually want to use `ConstantExpr` to store the evaluated initializer value 
of a `constexpr` variable (replacing the existing special-case caching on 
`VarDecl`) and the like, not only for immediate invocations, and once we start 
doing that for reference variables we'll have glvalue `ConstantExpr`s.

Is there some circumstance under which a glvalue `ConstantExpr`'s `APValue` 
result is not of kind `LValue`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76438/new/

https://reviews.llvm.org/D76438



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76451: [clangd] Enable textual fallback for go-to-definition on dependent names

[Nathan Ridge via Phabricator via cfe-commits]

nridge created this revision.
nridge added a reviewer: sammccall.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous, 
MaskRay, ilya-biryukov.
Herald added a project: clang.
nridge marked an inline comment as done.
nridge added inline comments.



Comment at: clang-tools-extra/clangd/XRefs.cpp:234
   ParsedAST , llvm::StringRef MainFilePath,
-  const SymbolIndex *Index) {
+  const SymbolIndex *Index, bool *IsDependentName) {
   const SourceManager  = AST.getSourceManager();

In the future, I can envision expanding this to return additional information, 
possibly the AST node itself. For now, I just started with a boolean.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76451

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/XRefs.h
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -647,14 +647,40 @@
 int myFunction(int);
 // Not triggered for token which survived preprocessing.
 int var = m^yFunction();
-  )cpp",
+  )cpp"};
+
+  for (const char *Test : Tests) {
+Annotations T(Test);
+llvm::Optional WantDecl;
+if (!T.ranges().empty())
+  WantDecl = T.range();
+
+auto TU = TestTU::withCode(T.code());
+
+auto AST = TU.build();
+auto Index = TU.index();
+auto Results = locateSymbolNamedTextuallyAt(
+AST, Index.get(),
+cantFail(sourceLocationInMainFile(AST.getSourceManager(), T.point())),
+testPath(TU.Filename), /*IsDependent=*/false);
+
+if (!WantDecl) {
+  EXPECT_THAT(Results, IsEmpty()) << Test;
+} else {
+  ASSERT_THAT(Results, ::testing::SizeIs(1)) << Test;
+  EXPECT_EQ(Results[0].PreferredDeclaration.range, *WantDecl) << Test;
+}
+  }
+} // namespace
+
+TEST(LocateSymbol, TextualDependent) {
+  const char *Tests[] = {
   R"cpp(// Dependent type
 struct Foo {
-  void uniqueMethodName();
+  void [[uniqueMethodName]]();
 };
 template 
 void f(T t) {
-  // Not triggered for token which survived preprocessing.
   t->u^niqueMethodName();
 }
   )cpp"};
@@ -669,10 +695,10 @@
 
 auto AST = TU.build();
 auto Index = TU.index();
-auto Results = locateSymbolNamedTextuallyAt(
-AST, Index.get(),
-cantFail(sourceLocationInMainFile(AST.getSourceManager(), T.point())),
-testPath(TU.Filename));
+// Need to use locateSymbolAt() since we are testing an
+// interaction between locateASTReferent() and
+// locateSymbolNamedTextuallyAt().
+auto Results = locateSymbolAt(AST, T.point(), Index.get());
 
 if (!WantDecl) {
   EXPECT_THAT(Results, IsEmpty()) << Test;
@@ -765,17 +791,18 @@
 struct Bar {
   void $BarLoc[[uniqueMethodName]]();
 };
-// Will call u^niqueMethodName() on t.
 template 
-void f(T t);
+void f(T t) {
+  t.u^niqueMethodName();
+}
   )cpp");
   auto TU = TestTU::withCode(T.code());
   auto AST = TU.build();
   auto Index = TU.index();
-  auto Results = locateSymbolNamedTextuallyAt(
-  AST, Index.get(),
-  cantFail(sourceLocationInMainFile(AST.getSourceManager(), T.point())),
-  testPath(TU.Filename));
+  // Need to use locateSymbolAt() since we are testing an
+  // interaction between locateASTReferent() and
+  // locateSymbolNamedTextuallyAt().
+  auto Results = locateSymbolAt(AST, T.point(), Index.get());
   EXPECT_THAT(Results,
   UnorderedElementsAre(Sym("uniqueMethodName", T.range("FooLoc")),
Sym("uniqueMethodName", T.range("BarLoc";
Index: clang-tools-extra/clangd/XRefs.h
===
--- clang-tools-extra/clangd/XRefs.h
+++ clang-tools-extra/clangd/XRefs.h
@@ -62,7 +62,7 @@
 std::vector
 locateSymbolNamedTextuallyAt(ParsedAST , const SymbolIndex *Index,
  SourceLocation Loc,
- const std::string );
+ const std::string , bool IsDependent);
 
 /// Get all document links
 std::vector getDocumentLinks(ParsedAST );
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -22,6 +22,7 @@
 #include "index/Relation.h"
 #include "index/SymbolLocation.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/Attrs.inc"
 #include "clang/AST/Decl.h"
@@ -136,19 +137,31 @@
   return Merged.CanonicalDeclaration;
 }
 

[PATCH] D66094: [CodeGen] Emit destructor calls for non-trivial C structs returned by function calls and loaded from volatile objects

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:677
+  E->getType().isDestructedType() == QualType::DK_nontrivial_c_struct)
+Cleanup.setExprNeedsCleanups(true);
+

rjmccall wrote:
> ahatanak wrote:
> > rjmccall wrote:
> > > ahatanak wrote:
> > > > rjmccall wrote:
> > > > > ahatanak wrote:
> > > > > > rjmccall wrote:
> > > > > > > Why only when the l-value is volatile?
> > > > > > I was trying to avoid emitting `ExprWithCleanups` when it wasn't 
> > > > > > needed and it seemed that it wasn't needed for non-volatile types. 
> > > > > > I'm not sure it's important, so I've removed the check for 
> > > > > > volatile. Also, `ExprWithCleanups` shouldn't' be emitted when this 
> > > > > > is in file scope, so I fixed that too.
> > > > > Hmm, not sure about this file-scope thing, since the combination of 
> > > > > C++ dynamic initializers and statement-expressions means  we can have 
> > > > > pretty unrestricted code there.
> > > > I should have explained why this was needed, but I wanted to prevent 
> > > > emitting `ExprWithCleanups` in the following example:
> > > > 
> > > > ```
> > > > struct A {
> > > >   id f0;
> > > > };
> > > > 
> > > > typedef struct A A;
> > > > 
> > > > A g = (A){ .f0 = 0 };
> > > > ```
> > > > 
> > > > The l-value to r-value conversion happens here because compound 
> > > > literals are l-values. Since `g` is a global of a non-trivial C struct 
> > > > type, we shouldn't try to push a cleanup and destruct the object.
> > > > 
> > > > We don't have to think about the C++ case since the line below checks 
> > > > the type is a non-trivial C type. I didn't think about statement 
> > > > expressions, but they aren't allowed in file scope, so I guess that's 
> > > > not a problem either.
> > > I would hope that the constant-evaluator here might be smart enough to 
> > > ignore some elidable temporaries.
> > Do you mean the constant-evaluator should evaluate initializers that are 
> > `ExprWithCleanups` to constants in a case like this?  It's possible to do 
> > so by seeing whether the sub-expression of `ExprWithCleanups` is constant, 
> > but it looks like we also have to set the 
> > `CleanupInfo::CleanupsHaveSideEffects` flag to false when it's a file scope 
> > expression so that `ConstExprEmitter::VisitExprWithCleanups` can 
> > constant-fold the `ExprWithCleanups` initializer.
> In this case, what we're doing is eliding a "temporary" (really an object 
> with wider lifetime, but if the object isn't referenceable, we can compile 
> as-if the object is really temporary) and therefore bypassing the need for a 
> cleanup entirely.  I wouldn't expect the AST to change to reflect that this 
> is possible, just the constant evaluator.  Basically, it needs to look 
> through `ExprWithCleanups`; we probably already peephole the 
> `LValueToRValue(CompoundLiteralExpr)` combination.
> 
> We do try to do constant-evaluation on local initializers as well as an 
> optimization, and abstractly that should also work with these constructs.
I taught `Expr::isConstantInitializer` to look through `ExprWithCleanups` and 
`ConstExprEmitter::VisitExprWithCleanups` to ignore whether the expression has 
side effects. For the latter, I'm assuming we don't have to care about the side 
effect of the cleanup if the need for a cleanup is elided. This change causes 
`CodeGenFunction::EmitAutoVarInit` to emit the initializer as a constant too.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66094/new/

https://reviews.llvm.org/D66094



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76447: Apply ConstantEvaluated evaluation contexts to more manifestly constant evaluated scopes

[Wyatt Childers via Phabricator via cfe-commits]

wchilders marked an inline comment as done.
wchilders added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:15597
+  (Rec.isConstantEvaluated() &&
+   Rec.ExprContext != ExpressionKind::EK_ConstexprVarInit)) {
 ExprCleanupObjects.erase(ExprCleanupObjects.begin() + 
Rec.NumCleanupObjects,

This is my main concern with this patch. There's something subtle here, and 
it's unclear from an outsider's (my) perspective what the root issue is here.

Effectively we get into trouble when we first enter 
`ActOnCXXEnterDeclInitializer` on the `isManifestlyEvaluatedVar` branch. We 
then exit at `ActOnCXXExitDeclInitializer`, triggering this branch, as 
`Rec.isConstantEvaluated()` is true. This results in the cleanups being 
dropped. Then when we enter the constexpr evaluator for 
`VarDecl::evaluateValue`. the evaluator is unhappy as we're missing a cleanup 
for the created temporary.

Any input that allows this to be resolved without the special case, or that 
otherwise informs how this should work, and why unevaluated and constant 
evaluated are treated equally here, would be awesome. I'll note that in 
reviewing the revision history, this condition dates back to when 
`ConstantEvaluated` was created, so perhaps this is a "historical artifact" of 
that time?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76447/new/

https://reviews.llvm.org/D76447



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76447: Apply ConstantEvaluated evaluation contexts to more manifestly constant evaluated scopes

[Wyatt Childers via Phabricator via cfe-commits]

wchilders created this revision.
wchilders added reviewers: Tyker, rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
wchilders marked an inline comment as done.
wchilders added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:15597
+  (Rec.isConstantEvaluated() &&
+   Rec.ExprContext != ExpressionKind::EK_ConstexprVarInit)) {
 ExprCleanupObjects.erase(ExprCleanupObjects.begin() + 
Rec.NumCleanupObjects,

This is my main concern with this patch. There's something subtle here, and 
it's unclear from an outsider's (my) perspective what the root issue is here.

Effectively we get into trouble when we first enter 
`ActOnCXXEnterDeclInitializer` on the `isManifestlyEvaluatedVar` branch. We 
then exit at `ActOnCXXExitDeclInitializer`, triggering this branch, as 
`Rec.isConstantEvaluated()` is true. This results in the cleanups being 
dropped. Then when we enter the constexpr evaluator for 
`VarDecl::evaluateValue`. the evaluator is unhappy as we're missing a cleanup 
for the created temporary.

Any input that allows this to be resolved without the special case, or that 
otherwise informs how this should work, and why unevaluated and constant 
evaluated are treated equally here, would be awesome. I'll note that in 
reviewing the revision history, this condition dates back to when 
`ConstantEvaluated` was created, so perhaps this is a "historical artifact" of 
that time?


This patch attempts to update application of evaluation contexts to better 
represent, what is manifestly constant evaluated.

There are some outstanding concerns I'll mark with inline comments.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76447

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/TreeTransform.h

Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -12079,6 +12079,8 @@
   // FIXME: Sema's lambda-building mechanism expects us to push an expression
   // evaluation context even if we're not transforming the function body.
   getSema().PushExpressionEvaluationContext(
+  E->getCallOperator()->getConstexprKind() == CSK_consteval ?
+  Sema::ExpressionEvaluationContext::ConstantEvaluated :
   Sema::ExpressionEvaluationContext::PotentiallyEvaluated);
 
   // Instantiate the body of the lambda expression.
Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -4644,7 +4644,10 @@
   Function->setInnerLocStart(PatternDecl->getInnerLocStart());
 
   EnterExpressionEvaluationContext EvalContext(
-  *this, Sema::ExpressionEvaluationContext::PotentiallyEvaluated);
+  *this,
+  PatternDecl->getConstexprKind() == CSK_consteval
+  ? Sema::ExpressionEvaluationContext::ConstantEvaluated
+  : Sema::ExpressionEvaluationContext::PotentiallyEvaluated);
 
   // Introduce a new scope where local variable instantiations will be
   // recorded, unless we're actually a member function within a local
@@ -4947,8 +4950,11 @@
 Var->setImplicitlyInline();
 
   if (OldVar->getInit()) {
+bool IsConstexpr = OldVar->isConstexpr() || isConstantEvaluated();
 EnterExpressionEvaluationContext Evaluated(
-*this, Sema::ExpressionEvaluationContext::PotentiallyEvaluated, Var);
+*this, getLangOpts().CPlusPlus2a && IsConstexpr ?
+Sema::ExpressionEvaluationContext::ConstantEvaluated :
+Sema::ExpressionEvaluationContext::PotentiallyEvaluated, Var);
 
 // Instantiate the initializer.
 ExprResult Init;
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -15369,9 +15369,16 @@
   }
 }
 
+// Check to see if this expression is part of a decltype specifier.
+// We're not interested in evaluating this expression, immediately or otherwise.
+static bool isInDeclType(Sema ) {
+  return SemaRef.ExprEvalContexts.back().ExprContext ==
+Sema::ExpressionEvaluationContextRecord::EK_Decltype;
+}
+
 ExprResult Sema::CheckForImmediateInvocation(ExprResult E, FunctionDecl *Decl) {
   if (!E.isUsable() || !Decl || !Decl->isConsteval() || isConstantEvaluated() ||
-  RebuildingImmediateInvocation)
+  isInDeclType(*this) || RebuildingImmediateInvocation)
 return E;
 
   /// Opportunistically remove the callee from ReferencesToConsteval if we can.
@@ -15532,11 +15539,12 @@
 }
 
 void Sema::PopExpressionEvaluationContext() {
+  using ExpressionKind = ExpressionEvaluationContextRecord::ExpressionKind;
+
 

[PATCH] D73898: [analyzer] StdLibraryFunctionsChecker: Add argument constraints

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus accepted this revision.
Szelethus added a comment.
This revision is now accepted and ready to land.

Whoo! The patch looks great and well thought out, the tests look like they 
cover everything and we also talked about plans for future patches. Excellent!

I left a nit about merging the test files, but I'll leave it up to you to 
address or ignore it.




Comment at: clang/test/Analysis/std-c-library-functions-arg-constraints.c:1-7
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctionArgs \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -triple x86_64-unknown-linux-gnu \
+// RUN:   -verify

martong wrote:
> Szelethus wrote:
> > Hmm, why do we have 2 different test files that essentially do the same? 
> > Shouldn't we only have a single one with `analyzer-output=text`?
> No, I wanted to have two different test files to test two different things: 
> (1) We do have the constraints applied (here we don't care about the warnings 
> and the path)
> (2) Check that we have a warning with the proper tracking and notes.
What if we had different `-verify`s? `clang/test/Analysis/track-conditions.cpp` 
is a great example.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73898/new/

https://reviews.llvm.org/D73898



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram marked an inline comment as done.
tmsriram added inline comments.



Comment at: clang/test/CodeGen/unique-internal-funcnames.c:3
+
+// RUN: %clang -target x86_64 -S -o - %s | FileCheck %s --check-prefix=PLAIN
+// RUN: %clang -target x86_64 -S -funique-internal-funcnames -o -  %s | 
FileCheck %s --check-prefix=UNIQUE

davidxl wrote:
> MaskRay wrote:
> > You can hardly find any .c -> .s test in clang/test. We mostly do .c -> .ll 
> > testing. `.ll` -> `.s` are in llvm/test/CodeGen. 
> Is this convention documented somewhere? Any concerns of producing .s?
There are more than 200 tests in clang that do -S from .c -> .s and tens of 
tests in CodeGen alone.  I can change this to .ll but curious where this 
"hardly any" comes from?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] b20ab41 - Teach TreeTransform to substitute into resolved TemplateArguments.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2020-03-19T12:43:11-07:00
New Revision: b20ab412bf838a8a87e5cc1c8c6399c3c9255354

URL: 
https://github.com/llvm/llvm-project/commit/b20ab412bf838a8a87e5cc1c8c6399c3c9255354
DIFF: 
https://github.com/llvm/llvm-project/commit/b20ab412bf838a8a87e5cc1c8c6399c3c9255354.diff

LOG: Teach TreeTransform to substitute into resolved TemplateArguments.

This comes up when substituting into an already-substituted template
argument during constraint satisfaction checking.

Added: 
clang/test/SemaTemplate/subst-into-subst.cpp

Modified: 
clang/lib/Sema/TreeTransform.h

Removed: 




diff  --git a/clang/lib/Sema/TreeTransform.h b/clang/lib/Sema/TreeTransform.h
index bc1a977dbd5d..e803300bbf16 100644
--- a/clang/lib/Sema/TreeTransform.h
+++ b/clang/lib/Sema/TreeTransform.h
@@ -4057,50 +4057,8 @@ template
 void TreeTransform::InventTemplateArgumentLoc(
  const TemplateArgument ,
  TemplateArgumentLoc ) {
-  SourceLocation Loc = getDerived().getBaseLocation();
-  switch (Arg.getKind()) {
-  case TemplateArgument::Null:
-llvm_unreachable("null template argument in TreeTransform");
-break;
-
-  case TemplateArgument::Type:
-Output = TemplateArgumentLoc(Arg,
-   SemaRef.Context.getTrivialTypeSourceInfo(Arg.getAsType(), Loc));
-
-break;
-
-  case TemplateArgument::Template:
-  case TemplateArgument::TemplateExpansion: {
-NestedNameSpecifierLocBuilder Builder;
-TemplateName Template = Arg.getAsTemplateOrTemplatePattern();
-if (DependentTemplateName *DTN = Template.getAsDependentTemplateName())
-  Builder.MakeTrivial(SemaRef.Context, DTN->getQualifier(), Loc);
-else if (QualifiedTemplateName *QTN = 
Template.getAsQualifiedTemplateName())
-  Builder.MakeTrivial(SemaRef.Context, QTN->getQualifier(), Loc);
-
-if (Arg.getKind() == TemplateArgument::Template)
-  Output = TemplateArgumentLoc(Arg,
-   
Builder.getWithLocInContext(SemaRef.Context),
-   Loc);
-else
-  Output = TemplateArgumentLoc(Arg,
-   
Builder.getWithLocInContext(SemaRef.Context),
-   Loc, Loc);
-
-break;
-  }
-
-  case TemplateArgument::Expression:
-Output = TemplateArgumentLoc(Arg, Arg.getAsExpr());
-break;
-
-  case TemplateArgument::Declaration:
-  case TemplateArgument::Integral:
-  case TemplateArgument::Pack:
-  case TemplateArgument::NullPtr:
-Output = TemplateArgumentLoc(Arg, TemplateArgumentLocInfo());
-break;
-  }
+  Output = getSema().getTrivialTemplateArgumentLoc(
+  Arg, QualType(), getDerived().getBaseLocation());
 }
 
 template
@@ -4110,12 +4068,45 @@ bool TreeTransform::TransformTemplateArgument(
   const TemplateArgument  = Input.getArgument();
   switch (Arg.getKind()) {
   case TemplateArgument::Null:
-  case TemplateArgument::Integral:
   case TemplateArgument::Pack:
-  case TemplateArgument::Declaration:
-  case TemplateArgument::NullPtr:
 llvm_unreachable("Unexpected TemplateArgument");
 
+  case TemplateArgument::Integral:
+  case TemplateArgument::NullPtr:
+  case TemplateArgument::Declaration: {
+// Transform a resolved template argument straight to a resolved template
+// argument. We get here when substituting into an already-substituted
+// template type argument during concept satisfaction checking.
+QualType T = Arg.getNonTypeTemplateArgumentType();
+QualType NewT = getDerived().TransformType(T);
+if (NewT.isNull())
+  return true;
+
+ValueDecl *D = Arg.getKind() == TemplateArgument::Declaration
+   ? Arg.getAsDecl()
+   : nullptr;
+ValueDecl *NewD = D ? cast_or_null(getDerived().TransformDecl(
+  getDerived().getBaseLocation(), D))
+: nullptr;
+if (D && !NewD)
+  return true;
+
+if (NewT == T && D == NewD)
+  Output = Input;
+else if (Arg.getKind() == TemplateArgument::Integral)
+  Output = TemplateArgumentLoc(
+  TemplateArgument(getSema().Context, Arg.getAsIntegral(), NewT),
+  TemplateArgumentLocInfo());
+else if (Arg.getKind() == TemplateArgument::NullPtr)
+  Output = TemplateArgumentLoc(TemplateArgument(NewT, /*IsNullPtr=*/true),
+   TemplateArgumentLocInfo());
+else
+  Output = TemplateArgumentLoc(TemplateArgument(NewD, NewT),
+   TemplateArgumentLocInfo());
+
+return false;
+  }
+
   case TemplateArgument::Type: {
 TypeSourceInfo *DI = Input.getTypeSourceInfo();
 if (!DI)

diff  --git a/clang/test/SemaTemplate/subst-into-subst.cpp 
b/clang/test/SemaTemplate/subst-into-subst.cpp
new file mode 100644
index ..69c4a837864d
--- /dev/null
+++ 

[PATCH] D76140: [InlineFunction] update attributes during inlining

[Anna Thomas via Phabricator via cfe-commits]

anna updated this revision to Diff 251447.
anna added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

fixed clang tests. rot-intrinsics.c testcase has 5 different RUNs with 3 
prefixes. Depending on target-triple, the attribute is added to the caller, so 
I've disabled the optimization for that specific test with 
-update-return-attrs=false


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76140/new/

https://reviews.llvm.org/D76140

Files:
  clang/test/CodeGen/builtins-systemz-zvector.c
  clang/test/CodeGen/builtins-systemz-zvector2.c
  clang/test/CodeGen/movbe-builtins.c
  clang/test/CodeGen/rot-intrinsics.c
  clang/test/CodeGen/waitpkg.c
  llvm/lib/Transforms/Utils/InlineFunction.cpp
  llvm/test/Transforms/Inline/ret_attr_update.ll

Index: llvm/test/Transforms/Inline/ret_attr_update.ll
===
--- /dev/null
+++ llvm/test/Transforms/Inline/ret_attr_update.ll
@@ -0,0 +1,75 @@
+; RUN: opt < %s -inline-threshold=0 -always-inline -S | FileCheck %s
+; RUN: opt < %s -passes=always-inline -S | FileCheck %s
+
+declare i8* @foo(i8*)
+declare i8* @bar(i8*)
+
+define i8* @callee(i8 *%p) alwaysinline {
+; CHECK: @callee(
+; CHECK: call i8* @foo(i8* noalias %p)
+  %r = call i8* @foo(i8* noalias %p)
+  ret i8* %r
+}
+
+define i8* @caller(i8* %ptr, i64 %x) {
+; CHECK-LABEL: @caller
+; CHECK: call nonnull i8* @foo(i8* noalias
+  %gep = getelementptr inbounds i8, i8* %ptr, i64 %x
+  %p = call nonnull i8* @callee(i8* %gep)
+  ret i8* %p
+}
+
+declare void @llvm.experimental.guard(i1,...)
+; Cannot add nonnull attribute to foo.
+define internal i8* @callee_with_throwable(i8* %p) alwaysinline {
+; CHECK-NOT: callee_with_throwable
+  %r = call i8* @foo(i8* %p)
+  %cond = icmp ne i8* %r, null
+  call void (i1, ...) @llvm.experimental.guard(i1 %cond) [ "deopt"() ]
+  ret i8* %r
+}
+
+; Here also we cannot add nonnull attribute to the call bar.
+define internal i8* @callee_with_explicit_control_flow(i8* %p) alwaysinline {
+; CHECK-NOT: callee_with_explicit_control_flow
+  %r = call i8* @bar(i8* %p)
+  %cond = icmp ne i8* %r, null
+  br i1 %cond, label %ret, label %orig
+
+ret:
+  ret i8* %r
+
+orig:
+  ret i8* %p
+}
+
+define i8* @caller2(i8* %ptr, i64 %x, i1 %cond) {
+; CHECK-LABEL: @caller2
+; CHECK: call i8* @foo
+; CHECK: call i8* @bar
+  %gep = getelementptr inbounds i8, i8* %ptr, i64 %x
+  %p = call nonnull i8* @callee_with_throwable(i8* %gep)
+  %q = call nonnull i8* @callee_with_explicit_control_flow(i8* %gep)
+  br i1 %cond, label %pret, label %qret
+
+pret:
+  ret i8* %p
+
+qret:
+  ret i8* %q
+}
+
+define internal i8* @callee3(i8 *%p) alwaysinline {
+; CHECK-NOT: callee3
+  %r = call noalias i8* @foo(i8* %p)
+  ret i8* %r
+}
+
+; add the deref attribute to the existing attributes on foo.
+define i8* @caller3(i8* %ptr, i64 %x) {
+; CHECK-LABEL: caller3
+; CHECK: call noalias dereferenceable_or_null(12) i8* @foo
+  %gep = getelementptr inbounds i8, i8* %ptr, i64 %x
+  %p = call dereferenceable_or_null(12) i8* @callee3(i8* %gep)
+  ret i8* %p
+}
Index: llvm/lib/Transforms/Utils/InlineFunction.cpp
===
--- llvm/lib/Transforms/Utils/InlineFunction.cpp
+++ llvm/lib/Transforms/Utils/InlineFunction.cpp
@@ -80,11 +80,21 @@
   cl::Hidden,
   cl::desc("Convert noalias attributes to metadata during inlining."));
 
+static cl::opt UpdateReturnAttributes(
+"update-return-attrs", cl::init(true), cl::Hidden,
+cl::desc("Update return attributes on calls within inlined body"));
+
 static cl::opt
 PreserveAlignmentAssumptions("preserve-alignment-assumptions-during-inlining",
   cl::init(true), cl::Hidden,
   cl::desc("Convert align attributes to assumptions during inlining."));
 
+static cl::opt MaxInstCheckedForThrow(
+"max-inst-checked-for-throw-during-inlining", cl::Hidden,
+cl::desc("the maximum number of instructions analyzed for may throw during "
+ "attribute inference in inlined body"),
+cl::init(4));
+
 llvm::InlineResult llvm::InlineFunction(CallBase *CB, InlineFunctionInfo ,
 AAResults *CalleeAAR,
 bool InsertLifetime) {
@@ -1136,6 +1146,77 @@
   }
 }
 
+static void AddReturnAttributes(CallSite CS, ValueToValueMapTy ) {
+  if (!UpdateReturnAttributes)
+return;
+  AttrBuilder AB(CS.getAttributes(), AttributeList::ReturnIndex);
+  if (AB.empty())
+return;
+
+  auto *CalledFunction = CS.getCalledFunction();
+  auto  = CalledFunction->getContext();
+
+  auto GetClonedValue = [&](Instruction *I) -> Value * {
+ValueToValueMapTy::iterator VMI = VMap.find(I);
+if (VMI == VMap.end())
+  return nullptr;
+return VMI->second;
+  };
+
+  auto MayContainThrowingCall = [&](Instruction *RVal, Instruction *RInst) {
+unsigned NumInstChecked = 0;
+for (auto  :
+ make_range(RVal->getIterator(), 

[PATCH] D76310: [Hexagon] Add linux #defines when linux triple is selected

[Sid Manning via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG430c9a80c17b: [Hexagon] Enable linux #defines (authored by 
sidneym).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76310/new/

https://reviews.llvm.org/D76310

Files:
  clang/lib/Basic/Targets.cpp
  clang/test/Preprocessor/hexagon-predefines.c


Index: clang/test/Preprocessor/hexagon-predefines.c
===
--- clang/test/Preprocessor/hexagon-predefines.c
+++ clang/test/Preprocessor/hexagon-predefines.c
@@ -101,3 +101,15 @@
 // RUN: -target-feature +hvxv67 -target-feature +hvx-length128b %s | FileCheck 
\
 // RUN: %s -check-prefix CHECK-ELF
 // CHECK-ELF: #define __ELF__ 1
+
+// RUN: %clang_cc1 -E -dM -triple hexagon-unknown-linux-musl \
+// RUN: -target-cpu hexagonv67 -target-feature +hvxv67 \
+// RUN: -target-feature +hvx-length128b %s | FileCheck \
+// RUN: %s -check-prefix CHECK-LINUX
+// CHECK-LINUX: #define __gnu_linux__ 1
+// CHECK-LINUX: #define __linux 1
+// CHECK-LINUX: #define __linux__ 1
+// CHECK-LINUX: #define __unix 1
+// CHECK-LINUX: #define __unix__ 1
+// CHECK-LINUX: #define linux 1
+// CHECK-LINUX: #define unix 1
Index: clang/lib/Basic/Targets.cpp
===
--- clang/lib/Basic/Targets.cpp
+++ clang/lib/Basic/Targets.cpp
@@ -117,6 +117,9 @@
 return new XCoreTargetInfo(Triple, Opts);
 
   case llvm::Triple::hexagon:
+if (os == llvm::Triple::Linux &&
+Triple.getEnvironment() == llvm::Triple::Musl)
+  return new LinuxTargetInfo(Triple, Opts);
 return new HexagonTargetInfo(Triple, Opts);
 
   case llvm::Triple::lanai:


Index: clang/test/Preprocessor/hexagon-predefines.c
===
--- clang/test/Preprocessor/hexagon-predefines.c
+++ clang/test/Preprocessor/hexagon-predefines.c
@@ -101,3 +101,15 @@
 // RUN: -target-feature +hvxv67 -target-feature +hvx-length128b %s | FileCheck \
 // RUN: %s -check-prefix CHECK-ELF
 // CHECK-ELF: #define __ELF__ 1
+
+// RUN: %clang_cc1 -E -dM -triple hexagon-unknown-linux-musl \
+// RUN: -target-cpu hexagonv67 -target-feature +hvxv67 \
+// RUN: -target-feature +hvx-length128b %s | FileCheck \
+// RUN: %s -check-prefix CHECK-LINUX
+// CHECK-LINUX: #define __gnu_linux__ 1
+// CHECK-LINUX: #define __linux 1
+// CHECK-LINUX: #define __linux__ 1
+// CHECK-LINUX: #define __unix 1
+// CHECK-LINUX: #define __unix__ 1
+// CHECK-LINUX: #define linux 1
+// CHECK-LINUX: #define unix 1
Index: clang/lib/Basic/Targets.cpp
===
--- clang/lib/Basic/Targets.cpp
+++ clang/lib/Basic/Targets.cpp
@@ -117,6 +117,9 @@
 return new XCoreTargetInfo(Triple, Opts);
 
   case llvm::Triple::hexagon:
+if (os == llvm::Triple::Linux &&
+Triple.getEnvironment() == llvm::Triple::Musl)
+  return new LinuxTargetInfo(Triple, Opts);
 return new HexagonTargetInfo(Triple, Opts);
 
   case llvm::Triple::lanai:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 430c9a8 - [Hexagon] Enable linux #defines

[Sid Manning via cfe-commits]

Author: Sid Manning
Date: 2020-03-19T14:33:49-05:00
New Revision: 430c9a80c17b00ec65b8254810e3c9e122d13f98

URL: 
https://github.com/llvm/llvm-project/commit/430c9a80c17b00ec65b8254810e3c9e122d13f98
DIFF: 
https://github.com/llvm/llvm-project/commit/430c9a80c17b00ec65b8254810e3c9e122d13f98.diff

LOG: [Hexagon] Enable linux #defines

Enable standard linux defines when the triple is Linux and the
environment is musl.

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

Added: 


Modified: 
clang/lib/Basic/Targets.cpp
clang/test/Preprocessor/hexagon-predefines.c

Removed: 




diff  --git a/clang/lib/Basic/Targets.cpp b/clang/lib/Basic/Targets.cpp
index c063f8ca4472..9181c715085e 100644
--- a/clang/lib/Basic/Targets.cpp
+++ b/clang/lib/Basic/Targets.cpp
@@ -117,6 +117,9 @@ TargetInfo *AllocateTarget(const llvm::Triple ,
 return new XCoreTargetInfo(Triple, Opts);
 
   case llvm::Triple::hexagon:
+if (os == llvm::Triple::Linux &&
+Triple.getEnvironment() == llvm::Triple::Musl)
+  return new LinuxTargetInfo(Triple, Opts);
 return new HexagonTargetInfo(Triple, Opts);
 
   case llvm::Triple::lanai:

diff  --git a/clang/test/Preprocessor/hexagon-predefines.c 
b/clang/test/Preprocessor/hexagon-predefines.c
index 5be8b96e290d..54013ceffa64 100644
--- a/clang/test/Preprocessor/hexagon-predefines.c
+++ b/clang/test/Preprocessor/hexagon-predefines.c
@@ -101,3 +101,15 @@
 // RUN: -target-feature +hvxv67 -target-feature +hvx-length128b %s | FileCheck 
\
 // RUN: %s -check-prefix CHECK-ELF
 // CHECK-ELF: #define __ELF__ 1
+
+// RUN: %clang_cc1 -E -dM -triple hexagon-unknown-linux-musl \
+// RUN: -target-cpu hexagonv67 -target-feature +hvxv67 \
+// RUN: -target-feature +hvx-length128b %s | FileCheck \
+// RUN: %s -check-prefix CHECK-LINUX
+// CHECK-LINUX: #define __gnu_linux__ 1
+// CHECK-LINUX: #define __linux 1
+// CHECK-LINUX: #define __linux__ 1
+// CHECK-LINUX: #define __unix 1
+// CHECK-LINUX: #define __unix__ 1
+// CHECK-LINUX: #define linux 1
+// CHECK-LINUX: #define unix 1



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76444: Use FinishThunk to finish musttail thunks

[Reid Kleckner via Phabricator via cfe-commits]

rnk created this revision.
rnk added reviewers: hans, rjmccall.
Herald added a project: clang.

FinishThunk, and the invariant of setting and then unsetting
CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't
exist when I added this musttail codepath in ab2090d10765 (2014).
Recently in 28328c3771, I started using this codepath on non-Windows
platforms, and users reported problems during release testing (PR44987).

The issue was already present for users of EH on i686-windows-msvc, so I
added a test for that case as well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76444

Files:
  clang/lib/CodeGen/CGVTables.cpp
  clang/test/CodeGenCXX/ms-thunks-ehspec.cpp
  clang/test/CodeGenCXX/thunks-ehspec.cpp


Index: clang/test/CodeGenCXX/thunks-ehspec.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/thunks-ehspec.cpp
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -fexceptions -fcxx-exceptions %s 
-triple=x86_64-pc-linux-gnu -munwind-tables -emit-llvm -o - -O1 
-disable-llvm-passes | FileCheck %s
+
+// When generating the thunk for secondary, do not push terminate scopes for
+// either the varargs or non-varargs case. Related to PR44987.
+
+struct A {
+  virtual void primary_key();
+};
+struct B {
+  virtual void secondary();
+  virtual void secondary_vararg(int, ...);
+};
+class C : A, B {
+  virtual void primary_key();
+  void secondary() noexcept;
+  void secondary_vararg(int, ...) noexcept;
+};
+void C::primary_key() {}
+
+// CHECK-LABEL: define available_externally void 
@_ZThn8_N1C9secondaryEv(%class.C* %this)
+// CHECK-NOT: invoke
+// CHECK: tail call void @_ZN1C9secondaryEv(%class.C* %{{.*}})
+// CHECK-NOT: invoke
+// CHECK: ret void
+
+// CHECK-LABEL: define available_externally void 
@_ZThn8_N1C16secondary_varargEiz(%class.C* %this, i32 %0, ...)
+// CHECK-NOT: invoke
+// CHECK:  musttail call void (%class.C*, i32, ...) 
@_ZN1C16secondary_varargEiz(%class.C* %{{.*}}, i32 %{{.*}}, ...) #2
+// CHECK-NEXT:  ret void
Index: clang/test/CodeGenCXX/ms-thunks-ehspec.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/ms-thunks-ehspec.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -fexceptions -fcxx-exceptions %s -triple=i686-windows-msvc 
-emit-llvm -o - | FileCheck %s
+
+// When generating thunks using musttail due to inalloca parameters, don't push
+// and pop terminate scopes. PR44987
+
+struct NonTrivial {
+  NonTrivial();
+  NonTrivial(const NonTrivial );
+  ~NonTrivial();
+  int x;
+};
+struct A {
+  virtual void f(NonTrivial o) noexcept;
+};
+struct B {
+  virtual void f(NonTrivial o) noexcept;
+};
+class C : A, B {
+  virtual void f(NonTrivial o) noexcept;
+};
+C c;
+
+// CHECK-LABEL: define linkonce_odr dso_local x86_thiscallcc void 
@"?f@C@@G3AEXUNonTrivial@@@Z"(%class.C* %this, <{ %struct.NonTrivial }>* 
inalloca %0)
+// CHECK-NOT: invoke
+// CHECK: musttail call x86_thiscallcc void 
@"?f@C@@EAEXUNonTrivial@@@Z"(%class.C* %{{.*}}, <{ %struct.NonTrivial }>* 
inalloca %0)
+// CHECK-NEXT  ret void
+
Index: clang/lib/CodeGen/CGVTables.cpp
===
--- clang/lib/CodeGen/CGVTables.cpp
+++ clang/lib/CodeGen/CGVTables.cpp
@@ -437,7 +437,8 @@
   // Finish the function to maintain CodeGenFunction invariants.
   // FIXME: Don't emit unreachable code.
   EmitBlock(createBasicBlock());
-  FinishFunction();
+
+  FinishThunk();
 }
 
 void CodeGenFunction::generateThunk(llvm::Function *Fn,
@@ -564,7 +565,7 @@
   CGM.SetLLVMFunctionAttributesForDefinition(GD.getDecl(), ThunkFn);
 
   // Thunks for variadic methods are special because in general variadic
-  // arguments cannot be perferctly forwarded. In the general case, clang
+  // arguments cannot be perfectly forwarded. In the general case, clang
   // implements such thunks by cloning the original function body. However, for
   // thunks with no return adjustment on targets that support musttail, we can
   // use musttail to perfectly forward the variadic arguments.


Index: clang/test/CodeGenCXX/thunks-ehspec.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/thunks-ehspec.cpp
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -fexceptions -fcxx-exceptions %s -triple=x86_64-pc-linux-gnu -munwind-tables -emit-llvm -o - -O1 -disable-llvm-passes | FileCheck %s
+
+// When generating the thunk for secondary, do not push terminate scopes for
+// either the varargs or non-varargs case. Related to PR44987.
+
+struct A {
+  virtual void primary_key();
+};
+struct B {
+  virtual void secondary();
+  virtual void secondary_vararg(int, ...);
+};
+class C : A, B {
+  virtual void primary_key();
+  void secondary() noexcept;
+  void secondary_vararg(int, ...) noexcept;
+};
+void C::primary_key() {}
+
+// CHECK-LABEL: define available_externally void @_ZThn8_N1C9secondaryEv(%class.C* %this)
+// CHECK-NOT: invoke
+// CHECK: tail call 

[PATCH] D76443: Use ConstantExpr cached APValues if present for code generation

[Wyatt Childers via Phabricator via cfe-commits]

wchilders added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:1095
+// preventing the cached results from being used.
+if (!isa(fe)) {
+  enterFullExpression(fe);

This one is a bit weird, I think the comment explains it well, but I feel there 
should be a better way to handle this or if there are similar issues lurking 
elsewhere.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76443/new/

https://reviews.llvm.org/D76443



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76443: Use ConstantExpr cached APValues if present for code generation

[Wyatt Childers via Phabricator via cfe-commits]

wchilders created this revision.
wchilders added reviewers: void, Tyker, rsmith.
Herald added subscribers: cfe-commits, jfb.
Herald added a project: clang.
wchilders added inline comments.



Comment at: clang/lib/CodeGen/CGStmt.cpp:1095
+// preventing the cached results from being used.
+if (!isa(fe)) {
+  enterFullExpression(fe);

This one is a bit weird, I think the comment explains it well, but I feel there 
should be a better way to handle this or if there are similar issues lurking 
elsewhere.


This patch allows code gen to use `APValue` Results from `ConstantExpr`s.

There are some outstanding concerns I'll mark with inline comments.

This is the codegen "sister patch" of: https://reviews.llvm.org/D76438


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76443

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/CodeGenModule.h

Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1390,6 +1390,21 @@
   /// \param QT is the clang QualType of the null pointer.
   llvm::Constant *getNullPointer(llvm::PointerType *T, QualType QT);
 
+  /// Try to emit the given expression as a constant; returns 0 if the
+  /// expression cannot be emitted as a constant.
+  llvm::Constant *EmitConstantExpr(const Expr *E, QualType DestType,
+   CodeGenFunction *CGF = nullptr);
+
+  /// Emit the given constant value as a constant, in the type's scalar
+  /// representation.
+  llvm::Constant *EmitConstantValue(const APValue , QualType DestType,
+CodeGenFunction *CGF = nullptr);
+
+  /// Emit the given constant value as a constant, in the type's memory
+  /// representation.
+  llvm::Constant *EmitConstantValueForMemory(const APValue ,
+ QualType DestType,
+ CodeGenFunction *CGF = nullptr);
 private:
   llvm::Constant *GetOrCreateLLVMFunction(
   StringRef MangledName, llvm::Type *Ty, GlobalDecl D, bool ForVTable,
Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -2289,6 +2289,8 @@
 TBAAAccessInfo *TBAAInfo = nullptr);
   LValue EmitLoadOfPointerLValue(Address Ptr, const PointerType *PtrTy);
 
+  llvm::Constant *EmitConstantValue(const APValue , QualType DestType);
+
   /// CreateTempAlloca - This creates an alloca and inserts it into the entry
   /// block if \p ArraySize is nullptr, otherwise inserts it at the current
   /// insertion point of the builder. The caller is responsible for setting an
Index: clang/lib/CodeGen/CodeGenFunction.cpp
===
--- clang/lib/CodeGen/CodeGenFunction.cpp
+++ clang/lib/CodeGen/CodeGenFunction.cpp
@@ -2529,3 +2529,9 @@
 
   return llvm::DebugLoc();
 }
+
+
+llvm::Constant *CodeGenFunction::EmitConstantValue(const APValue& Value,
+   QualType DestType) {
+  return CGM.EmitConstantValue(Value, DestType, this);
+}
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -1089,8 +1089,13 @@
   // statements following block literals with non-trivial cleanups.
   RunCleanupsScope cleanupScope(*this);
   if (const FullExpr *fe = dyn_cast_or_null(RV)) {
-enterFullExpression(fe);
-RV = fe->getSubExpr();
+// Constant expressions will emit their cached APValues, so
+// we don't want to handle this here, as it will unwrap them,
+// preventing the cached results from being used.
+if (!isa(fe)) {
+  enterFullExpression(fe);
+  RV = fe->getSubExpr();
+}
   }
 
   // FIXME: Clean this up by using an LValue for ReturnTemp,
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -433,7 +433,12 @@
   Value *VisitExpr(Expr *S);
 
   Value *VisitConstantExpr(ConstantExpr *E) {
-return Visit(E->getSubExpr());
+if (E->hasAPValueResult()) {
+  assert(!E->getType()->isVoidType());
+  return CGF.EmitConstantValue(E->getAPValueResult(), E->getType());
+} else {
+  return Visit(E->getSubExpr());
+}
   }
   Value *VisitParenExpr(ParenExpr *PE) {
 return Visit(PE->getSubExpr());
Index: clang/lib/CodeGen/CGExprConstant.cpp

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[David Li via Phabricator via cfe-commits]

davidxl added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1129
+  // should get unique names.  Use the hash of module name to get a unique
+  // identifier and this is a best effort.
+  if (getCodeGenOpts().UniqueInternalFuncNames &&

lebedev.ri wrote:
> maybe
> `identifier as this is a best-effort solution`
> 
Address review comment here.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1135
+llvm::MD5 Md5;
+Md5.update(getModule().getSourceFileName());
+llvm::MD5::MD5Result R;

Source filenames are not guaranteed to be unique, or it does contain the path 
as well?



Comment at: clang/test/CodeGen/unique-internal-funcnames.c:3
+
+// RUN: %clang -target x86_64 -S -o - %s | FileCheck %s --check-prefix=PLAIN
+// RUN: %clang -target x86_64 -S -funique-internal-funcnames -o -  %s | 
FileCheck %s --check-prefix=UNIQUE

MaskRay wrote:
> You can hardly find any .c -> .s test in clang/test. We mostly do .c -> .ll 
> testing. `.ll` -> `.s` are in llvm/test/CodeGen. 
Is this convention documented somewhere? Any concerns of producing .s?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] a983562 - Precommit test for clang::CallGraph declared functions.

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2020-03-19T12:00:30-07:00
New Revision: a983562b23458777a7226ec6cfe41cbeb9d291de

URL: 
https://github.com/llvm/llvm-project/commit/a983562b23458777a7226ec6cfe41cbeb9d291de
DIFF: 
https://github.com/llvm/llvm-project/commit/a983562b23458777a7226ec6cfe41cbeb9d291de.diff

LOG: Precommit test for clang::CallGraph declared functions.

https://reviews.llvm.org/D76435 fixes this problem, functions that are
being declared but ARE called aren't entered into the callgraph.

Added: 


Modified: 
clang/test/Analysis/debug-CallGraph.cpp

Removed: 




diff  --git a/clang/test/Analysis/debug-CallGraph.cpp 
b/clang/test/Analysis/debug-CallGraph.cpp
index 0f5a83b268a0..5453e2f21533 100644
--- a/clang/test/Analysis/debug-CallGraph.cpp
+++ b/clang/test/Analysis/debug-CallGraph.cpp
@@ -81,8 +81,26 @@ namespace Lambdas {
   }
 }
 
+namespace CallDecl {
+  void SomeDecl();
+  void SomeOtherDecl();
+  void SomeDef() {}
+
+  void Caller() {
+SomeDecl();
+SomeOtherDecl();
+  }
+
+  void SomeOtherDecl() {
+SomeDef();
+  }
+}
+
 // CHECK:--- Call graph Dump ---
-// CHECK-NEXT: {{Function: < root > calls: get5 add test_add mmm foo aaa < > 
bbb ddd ccc eee fff do_nothing test_single_call SomeNS::templ SomeNS::templ 
SomeNS::templUser Lambdas::Callee Lambdas::f1 Lambdas::f1\(\)::\(anonymous 
class\)::operator\(\) Lambdas::f1\(\)::\(anonymous class\)::operator\(\) $}}
+// CHECK-NEXT: {{Function: < root > calls: get5 add test_add mmm foo aaa < > 
bbb ddd ccc eee fff do_nothing test_single_call SomeNS::templ SomeNS::templ 
SomeNS::templUser Lambdas::Callee Lambdas::f1 Lambdas::f1\(\)::\(anonymous 
class\)::operator\(\) Lambdas::f1\(\)::\(anonymous class\)::operator\(\) 
CallDecl::SomeDef CallDecl::Caller CallDecl::SomeOtherDecl $}}
+// CHECK-NEXT: {{Function: CallDecl::Caller calls: CallDecl::SomeOtherDecl $}}
+// CHECK-NEXT: {{Function: CallDecl::SomeOtherDecl calls: CallDecl::SomeDef $}}
+// CHECK-NEXT: {{Function: CallDecl::SomeDef calls: $}}
 // CHECK-NEXT: {{Function: Lambdas::f1 calls: Lambdas::f1\(\)::\(anonymous 
class\)::operator\(\) Lambdas::f1\(\)::\(anonymous class\)::operator\(\) $}}
 // CHECK-NEXT: {{Function: Lambdas::f1\(\)::\(anonymous class\)::operator\(\) 
calls: Lambdas::Callee $}}
 // CHECK-NEXT: {{Function: Lambdas::f1\(\)::\(anonymous class\)::operator\(\) 
calls: Lambdas::Callee $}}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[David Li via Phabricator via cfe-commits]

davidxl added a comment.

As far as I understand, this is not a propeller specific patch, but it fixes a 
general problem in AFDO as well. Perhaps change the summary to reflect that?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76238: [SveEmitter] Implement builtins for contiguous loads/stores

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/include/clang/Basic/AArch64SVETypeFlags.h:72
+  bool isStructStore() const { return Flags & IsStructStore; }
+  bool isZxtReturn() const { return Flags & IsZxtReturn; }
+

SjoerdMeijer wrote:
> nit: this one is non obvious (at least to me), so perhaps worth a comment 
> what this is. I can guess that Zext means zero extending, but you know, the 
> context...
"Zxt" is not a standard abbreviation in LLVM: please use "Zext", or 
"ZeroExtend".



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7471
+
+Value *CodeGenFunction::EmitSVEMaskedStore(llvm::Type *ReturnTy,
+   SmallVectorImpl ,

ReturnTy is unused?



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7475
+  llvm::PointerType *PTy = cast(Ops[1]->getType());
+  llvm::Type *MemEltTy = PTy->getPointerElementType();
+

Please avoid using getPointerElementType where possible... it will interfere 
with opaque pointer types work.  (You should be able to get the element type 
from the AST.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76238/new/

https://reviews.llvm.org/D76238



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1129
+  // should get unique names.  Use the hash of module name to get a unique
+  // identifier and this is a best effort.
+  if (getCodeGenOpts().UniqueInternalFuncNames &&

maybe
`identifier as this is a best-effort solution`




Comment at: clang/test/CodeGen/unique-internal-funcnames.c:16
+// UNIQUE-NOT: foo:
+// UNIQUE: foo.{{[0-9a-f]+}}:

What does `getModule().getSourceFileName()` contain?
The full path to the source file, or just the source file basename?
If latter, maybe check the full name?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74918: Add method to TargetInfo to get CPU cache line size

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D74918#1931488 , @zoecarver wrote:

> @lebedev.ri LLVM may be better, I'm not sure. If you feel strongly I can move 
> it.


I do think that it makes much more sense somewhere closer to the backend

> @jyknight I'm planning on adding a builtin that uses this method. I can put 
> the patch up for that first if you would like.

but that being said, currently nothing needs that and with all those concerns 
about exposing this info,
i'd hold off moving it until it is settled whether it is needed (and not a dead 
code) in the first place :/


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74918/new/

https://reviews.llvm.org/D74918



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76416: [ASan] Apply -ffile-prefix-map mappings to ASan instrumentation

[Leonard Chan via Phabricator via cfe-commits]

leonardchan updated this revision to Diff 251421.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76416/new/

https://reviews.llvm.org/D76416

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/CodeGen/SanitizerMetadata.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/asan-globals-file-prefix-map.cpp
  llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/test/Instrumentation/AddressSanitizer/asan_file_prefix_map.ll
  llvm/test/Instrumentation/AddressSanitizer/asan_no_file_prefix_map.ll

Index: llvm/test/Instrumentation/AddressSanitizer/asan_no_file_prefix_map.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/AddressSanitizer/asan_no_file_prefix_map.ll
@@ -0,0 +1,20 @@
+; RUN: opt < %s -asan -asan-module -S | FileCheck %s
+
+target triple = "x86_64-unknown-linux-gnu"
+
+@global = global i32 0, align 4
+@global2 = global i32 0, align 4
+
+; Check that the string used for the source location has its original prefix.
+; CHECK: @___asan_gen_.{{[0-9]+}} = private unnamed_addr constant [22 x i8] c"/tmp/asan-globals.cpp\00", align 1
+; CHECK: @___asan_gen_.{{[0-9]+}} = private unnamed_addr constant [22 x i8] c"blah/asan-globals.cpp\00", align 1
+
+!llvm.asan.globals = !{!0, !1}
+!101 = !{!"/tmp", !"/some/other/tmp"}
+!102 = !{!"blah", !"../some/other/blah"}
+
+!0 = !{i32* @global, !6, !"global", i1 false, i1 false}
+!1 = !{i32* @global2, !7, !"global2", i1 false, i1 false}
+
+!6 = !{!"/tmp/asan-globals.cpp", i32 5, i32 5}
+!7 = !{!"blah/asan-globals.cpp", i32 5, i32 5}
Index: llvm/test/Instrumentation/AddressSanitizer/asan_file_prefix_map.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/AddressSanitizer/asan_file_prefix_map.ll
@@ -0,0 +1,21 @@
+; RUN: opt < %s -asan -asan-module -S | FileCheck %s
+
+target triple = "x86_64-unknown-linux-gnu"
+
+@global = global i32 0, align 4
+@global2 = global i32 0, align 4
+
+; Check that the string used for the source location has it's prefix replaced if llvm.asan.file.prefix.map is present.
+; CHECK: @___asan_gen_.{{[0-9]+}} = private unnamed_addr constant [33 x i8] c"/some/other/tmp/asan-globals.cpp\00", align 1
+; CHECK: @___asan_gen_.{{[0-9]+}} = private unnamed_addr constant [36 x i8] c"../some/other/blah/asan-globals.cpp\00", align 1
+
+!llvm.asan.globals = !{!0, !1}
+!llvm.asan.file.prefix.map = !{!101, !102}
+!101 = !{!"/tmp", !"/some/other/tmp"}
+!102 = !{!"blah", !"../some/other/blah"}
+
+!0 = !{i32* @global, !6, !"global", i1 false, i1 false}
+!1 = !{i32* @global2, !7, !"global2", i1 false, i1 false}
+
+!6 = !{!"/tmp/asan-globals.cpp", i32 5, i32 5}
+!7 = !{!"blah/asan-globals.cpp", i32 5, i32 5}
Index: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -1151,6 +1151,26 @@
 mdconst::extract(MDN->getOperand(4));
 E.IsBlacklisted |= IsBlacklisted->isOne();
   }
+
+  // Go through the file prefix map to replace prefixes in metadata that may
+  // contain filepaths. Do this once in the globals metadata pass so we don't
+  // need to run over the map in ASan for each metadata instance.
+  NamedMDNode *PrefixMap = M.getNamedMetadata("llvm.asan.file.prefix.map");
+  if (!PrefixMap)
+return;
+  for (auto  : Entries) {
+for (auto *MDN : PrefixMap->operands()) {
+  assert(MDN->getNumOperands() == 2 &&
+ "Each node in the prefix map should be a pair");
+  StringRef Prefix = cast(MDN->getOperand(0))->getString();
+  StringRef Replacement = cast(MDN->getOperand(1))->getString();
+  if (llvm::sys::path::replace_path_prefix(
+  Entry.second.SourceLoc.Filename, Prefix, Replacement,
+  llvm::sys::path::Style::native, true)) {
+break;
+  }
+}
+  }
 }
 
 AnalysisKey ASanGlobalsMetadataAnalysis::Key;
Index: llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h
===
--- llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h
+++ llvm/include/llvm/Transforms/Instrumentation/AddressSanitizer.h
@@ -22,7 +22,7 @@
 
 /// Frontend-provided metadata for source location.
 struct LocationMetadata {
-  StringRef Filename;
+  llvm::SmallString<64> Filename;
   int LineNo = 0;
   int ColumnNo = 0;
 
Index: clang/test/CodeGen/asan-globals-file-prefix-map.cpp
===
--- /dev/null
+++ clang/test/CodeGen/asan-globals-file-prefix-map.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 %s -fsanitize=address -ffile-prefix-map=%S=/tmp -S 

[PATCH] D76130: [PPC][AIX] Implement variadic function handling in LowerFormalArguments_AIX

[Zarko Todorovski via Phabricator via cfe-commits]

ZarkoCA added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:7076
+static const MCPhysReg GPR_64[] = {PPC::X3, PPC::X4, PPC::X5, PPC::X6,
+   PPC::X7, PPC::X8, PPC::X9, PPC::X10};
+unsigned const NumGPArgRegs = array_lengthof(GPR_32);

jasonliu wrote:
> This two array gets used to in CC_AIX and here. It would be great if we only 
> have one set of copy. 
I agree, but the array is local to CC_AIX as far as I understand and there is 
not a good way to access it from here without having to modify CC_AIX.  I think 
it would be a good to do it at a later point when it's not undergoing so much 
change already. 



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:7014
 
 if (VA.isRegLoc()) {
   MVT::SimpleValueType SVT = ValVT.getSimpleVT().SimpleTy;

jasonliu wrote:
> Do we need  `&& !VA.needsCustom() ` here?
Yes, it's better if I add it, thanks.



Comment at: llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-32.ll:1
+; RUN: llc -O2 -mtriple powerpc-ibm-aix-xcoff -stop-after=machine-cp 
-mattr=-altivec -verify-machineinstrs < %s | \
+; RUN: FileCheck --check-prefixes=CHECK,32BIT %s

jasonliu wrote:
> Do we need '-O2' specified here and below?
It makes the IR and assembly much cleaner and easier to read, imo. 



Comment at: llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-32.ll:7
+; RUN: FileCheck --check-prefixes=CHECKASM,ASM32PWR4 %s
+
+declare void @llvm.lifetime.start.p0i8(i64 immarg, i8* nocapture)

jasonliu wrote:
> A general comment about how to test va_arg.
> I think the two test cases we have here are not enough. 
> On top of my head I would probably add in getting double as va_arg argument, 
> uses of va_copy and so on. 
> It's probably worth checking how other targets test va_arg. Grep "va_start" 
> in llvm/test/CodeGen would give you a lot of hit. 
Yes, I can clean up the tests and add more.  Agreed we need more and I can 
simplify them so it's clear what's being tested. 



Comment at: llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-32.ll:15
+
+@a = local_unnamed_addr global i32 1, align 4
+@b = local_unnamed_addr global i32 2, align 4

jasonliu wrote:
> These variables didn't get used anywhere.
Removed, but as I said earlier, I'll also do a rework of the tests. 



Comment at: llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-32.ll:27
+; Function Attrs: nounwind
+define i32 @va_arg1(i32 %a, ...) local_unnamed_addr {
+entry:

jasonliu wrote:
> These tests used for loops to call va_arg mutliple times. 
> Maybe it's just me, but I found the test cases are much harder to read. 
> I would suggest maybe just unroll the for loop and generate as much as the 
> va_arg call that you need? 
> 
> For the cases below, I suppose you would want to call va_arg 9 times, and 2 
> times respectfully. Maybe it's not that bad. If the tests gets too long, you 
> could consider split the tests into separate files. 
Yes, see reply above, I will rework the tests. 



Comment at: llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-32.ll:33
+  call void @llvm.va_start(i8* nonnull %0)
+  %cmp7 = icmp sgt i32 %a, 0
+  br i1 %cmp7, label %for.body.preheader, label %for.end

jasonliu wrote:
> a is 1, so we would only call va_arg once, despite we have 9 vaarg argument. 
> Is this the intention of the test?
a = 1 doesn't mean we call va_arg once. This is the IR for the function 
definition that I got using this c code (modified for this example): 
```
a = 1;
int va_arg1(int a,...) {
...
}
```
The callee doesn't know how many vararg arguments will be called, just does the 
setup for the variadic parameter (...) in the IR. 



Comment at: llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-32.ll:162
+  %add7 = add nsw i32 %add6, %eight
+  %cmp15 = icmp sgt i32 %eight, 0
+  br i1 %cmp15, label %for.body.preheader, label %for.end

jasonliu wrote:
> We only have 2 va_arg arguments here, but we called va_arg 8 times? I think 
> that's undefined behavior. 
Seem my reply above.  That said, there is some confusion with respect to tests 
and they'll be reworked.  


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76130/new/

https://reviews.llvm.org/D76130



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76438: ConstantExpr cached APValues if present for constant evaluation

[Wyatt Childers via Phabricator via cfe-commits]

wchilders added inline comments.



Comment at: clang/lib/AST/Expr.cpp:2875
 
-  else if (auto *CE = dyn_cast(E))
-return CE->getSubExpr();
-
   return E;
 }

`IgnoreParensSingleStep` for some reason has been unwrapping `ConstantExpr`s. 
This results in the constant evaluator, removing the ConstantExpr, and 
reevaluating the expression. There are no observed downsides to removing this 
condition, in the test suite, however, it's strange enough to note.



Comment at: clang/lib/AST/ExprConstant.cpp:7329
+  if (Result.isLValue())
+return Success(Result, E);
+}

This doesn't seem to be the right answer, and `ConstantExpr`s don't have 
`LValue` `APValue`s, at least, not that are reaching this case. We had a 
previous implementation that also, kind of punted on this issue with an 
override in `TemporaryExprEvaluator`: 
https://gitlab.com/lock3/clang/-/blob/9fbaeea06fc567ac472264bec2a72661a1e06c73/clang/lib/AST/ExprConstant.cpp#L9753


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76438/new/

https://reviews.llvm.org/D76438



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76438: ConstantExpr cached APValues if present for constant evaluation

[Wyatt Childers via Phabricator via cfe-commits]

wchilders created this revision.
wchilders added reviewers: Tyker, rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch allows the constant evaluator to use `APValueResult`s from 
`ConstantExpr`s.

There are some outstanding concerns I'll mark with inline comments.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76438

Files:
  clang/include/clang/AST/Expr.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp


Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -6751,8 +6751,13 @@
 return Error(E);
   }
 
-  bool VisitConstantExpr(const ConstantExpr *E)
-{ return StmtVisitorTy::Visit(E->getSubExpr()); }
+  bool VisitConstantExpr(const ConstantExpr *E) {
+if (E->hasAPValueResult())
+  return DerivedSuccess(E->getAPValueResult(), E);
+
+return StmtVisitorTy::Visit(E->getSubExpr());
+  }
+
   bool VisitParenExpr(const ParenExpr *E)
 { return StmtVisitorTy::Visit(E->getSubExpr()); }
   bool VisitUnaryExtension(const UnaryOperator *E)
@@ -7317,6 +7322,16 @@
 return true;
   }
 
+  bool VisitConstantExpr(const ConstantExpr *E) {
+if (E->hasAPValueResult()) {
+  APValue Result = E->getAPValueResult();
+  if (Result.isLValue())
+return Success(Result, E);
+}
+
+return ExprEvaluatorBaseTy::Visit(E->getSubExpr());
+  }
+
   bool VisitMemberExpr(const MemberExpr *E) {
 // Handle non-static data members.
 QualType BaseTy;
Index: clang/lib/AST/Expr.cpp
===
--- clang/lib/AST/Expr.cpp
+++ clang/lib/AST/Expr.cpp
@@ -356,6 +356,8 @@
 }
 
 APValue ConstantExpr::getAPValueResult() const {
+  assert(hasAPValueResult());
+
   switch (ConstantExprBits.ResultKind) {
   case ConstantExpr::RSK_APValue:
 return APValueResult();
@@ -2870,9 +2872,6 @@
   return CE->getChosenSubExpr();
   }
 
-  else if (auto *CE = dyn_cast(E))
-return CE->getSubExpr();
-
   return E;
 }
 
Index: clang/include/clang/AST/Expr.h
===
--- clang/include/clang/AST/Expr.h
+++ clang/include/clang/AST/Expr.h
@@ -1063,6 +1063,9 @@
   bool isImmediateInvocation() const {
 return ConstantExprBits.IsImmediateInvocation;
   }
+  bool hasAPValueResult() const {
+return ConstantExprBits.APValueKind != APValue::None;
+  }
   APValue getAPValueResult() const;
   APValue () const { return APValueResult(); }
   llvm::APSInt getResultAsAPSInt() const;


Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -6751,8 +6751,13 @@
 return Error(E);
   }
 
-  bool VisitConstantExpr(const ConstantExpr *E)
-{ return StmtVisitorTy::Visit(E->getSubExpr()); }
+  bool VisitConstantExpr(const ConstantExpr *E) {
+if (E->hasAPValueResult())
+  return DerivedSuccess(E->getAPValueResult(), E);
+
+return StmtVisitorTy::Visit(E->getSubExpr());
+  }
+
   bool VisitParenExpr(const ParenExpr *E)
 { return StmtVisitorTy::Visit(E->getSubExpr()); }
   bool VisitUnaryExtension(const UnaryOperator *E)
@@ -7317,6 +7322,16 @@
 return true;
   }
 
+  bool VisitConstantExpr(const ConstantExpr *E) {
+if (E->hasAPValueResult()) {
+  APValue Result = E->getAPValueResult();
+  if (Result.isLValue())
+return Success(Result, E);
+}
+
+return ExprEvaluatorBaseTy::Visit(E->getSubExpr());
+  }
+
   bool VisitMemberExpr(const MemberExpr *E) {
 // Handle non-static data members.
 QualType BaseTy;
Index: clang/lib/AST/Expr.cpp
===
--- clang/lib/AST/Expr.cpp
+++ clang/lib/AST/Expr.cpp
@@ -356,6 +356,8 @@
 }
 
 APValue ConstantExpr::getAPValueResult() const {
+  assert(hasAPValueResult());
+
   switch (ConstantExprBits.ResultKind) {
   case ConstantExpr::RSK_APValue:
 return APValueResult();
@@ -2870,9 +2872,6 @@
   return CE->getChosenSubExpr();
   }
 
-  else if (auto *CE = dyn_cast(E))
-return CE->getSubExpr();
-
   return E;
 }
 
Index: clang/include/clang/AST/Expr.h
===
--- clang/include/clang/AST/Expr.h
+++ clang/include/clang/AST/Expr.h
@@ -1063,6 +1063,9 @@
   bool isImmediateInvocation() const {
 return ConstantExprBits.IsImmediateInvocation;
   }
+  bool hasAPValueResult() const {
+return ConstantExprBits.APValueKind != APValue::None;
+  }
   APValue getAPValueResult() const;
   APValue () const { return APValueResult(); }
   llvm::APSInt getResultAsAPSInt() const;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76098: [clangd] Do not trigger go-to-def textual fallback inside string literals

[Nathan Ridge via Phabricator via cfe-commits]

nridge updated this revision to Diff 251418.
nridge added a comment.

Take a blacklisting approach


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76098/new/

https://reviews.llvm.org/D76098

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -628,7 +628,8 @@
 // Comment mentioning M^yClass
   )cpp",
   R"cpp(// String
-struct [[MyClass]] {};
+struct MyClass {};
+// Not triggered for string literal tokens.
 const char* s = "String literal mentioning M^yClass";
   )cpp",
   R"cpp(// Ifdef'ed out code
@@ -680,7 +681,7 @@
   EXPECT_EQ(Results[0].PreferredDeclaration.range, *WantDecl) << Test;
 }
   }
-}
+} // namespace
 
 TEST(LocateSymbol, Ambiguous) {
   auto T = Annotations(R"cpp(
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -374,6 +374,17 @@
   unsigned WordOffset = Word.data() - Code.data();
   SourceLocation WordStart = SM.getComposedLoc(File, WordOffset);
 
+  // Attempt to determine the kind of token that contains the word,
+  // and bail if it's a string literal. Note that we cannot always
+  // determine the token kind (e.g. comments, for which we do want
+  // to activate, are not retained by TokenBuffer).
+  for (syntax::Token T : syntax::spelledTokensTouching(Loc, AST.getTokens())) {
+if (T.range(AST.getSourceManager()).touches(WordOffset + Word.size())) {
+  if (isStringLiteral(T.kind()))
+return {};
+}
+  }
+
   // Do not consider tokens that survived preprocessing.
   // We are erring on the safe side here, as a user may expect to get
   // accurate (as opposed to textual-heuristic) results for such tokens.


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -628,7 +628,8 @@
 // Comment mentioning M^yClass
   )cpp",
   R"cpp(// String
-struct [[MyClass]] {};
+struct MyClass {};
+// Not triggered for string literal tokens.
 const char* s = "String literal mentioning M^yClass";
   )cpp",
   R"cpp(// Ifdef'ed out code
@@ -680,7 +681,7 @@
   EXPECT_EQ(Results[0].PreferredDeclaration.range, *WantDecl) << Test;
 }
   }
-}
+} // namespace
 
 TEST(LocateSymbol, Ambiguous) {
   auto T = Annotations(R"cpp(
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -374,6 +374,17 @@
   unsigned WordOffset = Word.data() - Code.data();
   SourceLocation WordStart = SM.getComposedLoc(File, WordOffset);
 
+  // Attempt to determine the kind of token that contains the word,
+  // and bail if it's a string literal. Note that we cannot always
+  // determine the token kind (e.g. comments, for which we do want
+  // to activate, are not retained by TokenBuffer).
+  for (syntax::Token T : syntax::spelledTokensTouching(Loc, AST.getTokens())) {
+if (T.range(AST.getSourceManager()).touches(WordOffset + Word.size())) {
+  if (isStringLiteral(T.kind()))
+return {};
+}
+  }
+
   // Do not consider tokens that survived preprocessing.
   // We are erring on the safe side here, as a user may expect to get
   // accurate (as opposed to textual-heuristic) results for such tokens.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76360: [PPC][AIX] Emit correct Vaarg for 32BIT-AIX in clang

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4176
+/// PPC32_SVR4_ABIInfo - The 32-bit PowerPC ABI information, used by PowerPC 
ELF
+/// (SVR4), Darwin and AIX.
 class PPC32_SVR4_ABIInfo : public DefaultABIInfo {

I would suggest using an "Oxford comma" before the "and". Also, colon instead 
of comma before "used".



Comment at: clang/test/CodeGen/aix-vararg.c:4
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -emit-llvm -o - %s | 
FileCheck %s --check-prefix=32BIT
+#include 
+

ZarkoCA wrote:
> hubert.reinterpretcast wrote:
> > Can we use built-in types and functions in place of a header inclusion?
> I'm worried about legal/copyright issues with using contents from AIX system 
> headers to LLVM testcases. But I can do that for sure once I understand what 
> I am allowed to do.   
I just mean:
`__builtin_va_list`
`__builtin_va_start`
`__builtin_va_copy`
`__builtin_va_arg`
`__builtin_va_end`



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76360/new/

https://reviews.llvm.org/D76360



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/test/CodeGen/unique-internal-funcnames.c:3
+
+// RUN: %clang -target x86_64 -S -o - %s | FileCheck %s --check-prefix=PLAIN
+// RUN: %clang -target x86_64 -S -funique-internal-funcnames -o -  %s | 
FileCheck %s --check-prefix=UNIQUE

You can hardly find any .c -> .s test in clang/test. We mostly do .c -> .ll 
testing. `.ll` -> `.s` are in llvm/test/CodeGen. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76396: Allow immediate invocation of constructors

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D76396#1930773 , @Tyker wrote:

> I have already a patch aiming to do the same thing. D74007 
> 


Thanks. Sorry I dropped the ball on that one. =/


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76396/new/

https://reviews.llvm.org/D76396



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66094: [CodeGen] Emit destructor calls for non-trivial C structs returned by function calls and loaded from volatile objects

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:677
+  E->getType().isDestructedType() == QualType::DK_nontrivial_c_struct)
+Cleanup.setExprNeedsCleanups(true);
+

ahatanak wrote:
> rjmccall wrote:
> > ahatanak wrote:
> > > rjmccall wrote:
> > > > ahatanak wrote:
> > > > > rjmccall wrote:
> > > > > > Why only when the l-value is volatile?
> > > > > I was trying to avoid emitting `ExprWithCleanups` when it wasn't 
> > > > > needed and it seemed that it wasn't needed for non-volatile types. 
> > > > > I'm not sure it's important, so I've removed the check for volatile. 
> > > > > Also, `ExprWithCleanups` shouldn't' be emitted when this is in file 
> > > > > scope, so I fixed that too.
> > > > Hmm, not sure about this file-scope thing, since the combination of C++ 
> > > > dynamic initializers and statement-expressions means  we can have 
> > > > pretty unrestricted code there.
> > > I should have explained why this was needed, but I wanted to prevent 
> > > emitting `ExprWithCleanups` in the following example:
> > > 
> > > ```
> > > struct A {
> > >   id f0;
> > > };
> > > 
> > > typedef struct A A;
> > > 
> > > A g = (A){ .f0 = 0 };
> > > ```
> > > 
> > > The l-value to r-value conversion happens here because compound literals 
> > > are l-values. Since `g` is a global of a non-trivial C struct type, we 
> > > shouldn't try to push a cleanup and destruct the object.
> > > 
> > > We don't have to think about the C++ case since the line below checks the 
> > > type is a non-trivial C type. I didn't think about statement expressions, 
> > > but they aren't allowed in file scope, so I guess that's not a problem 
> > > either.
> > I would hope that the constant-evaluator here might be smart enough to 
> > ignore some elidable temporaries.
> Do you mean the constant-evaluator should evaluate initializers that are 
> `ExprWithCleanups` to constants in a case like this?  It's possible to do so 
> by seeing whether the sub-expression of `ExprWithCleanups` is constant, but 
> it looks like we also have to set the `CleanupInfo::CleanupsHaveSideEffects` 
> flag to false when it's a file scope expression so that 
> `ConstExprEmitter::VisitExprWithCleanups` can constant-fold the 
> `ExprWithCleanups` initializer.
In this case, what we're doing is eliding a "temporary" (really an object with 
wider lifetime, but if the object isn't referenceable, we can compile as-if the 
object is really temporary) and therefore bypassing the need for a cleanup 
entirely.  I wouldn't expect the AST to change to reflect that this is 
possible, just the constant evaluator.  Basically, it needs to look through 
`ExprWithCleanups`; we probably already peephole the 
`LValueToRValue(CompoundLiteralExpr)` combination.

We do try to do constant-evaluation on local initializers as well as an 
optimization, and abstractly that should also work with these constructs.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D66094/new/

https://reviews.llvm.org/D66094



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76393: Allow remapping the sysroot with -fdebug-prefix-map.

[Adrian Prantl via Phabricator via cfe-commits]

aprantl updated this revision to Diff 251412.
aprantl added a comment.
Herald added a subscriber: hiraditya.

Don't try to be too clever with the strings.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76393/new/

https://reviews.llvm.org/D76393

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-prefix-map.c
  llvm/lib/DWARFLinker/DWARFLinker.cpp


Index: llvm/lib/DWARFLinker/DWARFLinker.cpp
===
--- llvm/lib/DWARFLinker/DWARFLinker.cpp
+++ llvm/lib/DWARFLinker/DWARFLinker.cpp
@@ -1914,12 +1914,13 @@
   return 0;
 }
 
-static std::string remapPath(StringRef Path,
+static std::string remapPath(std::string Path,
  const objectPrefixMap ) {
+  StringRef PathRef(Path);
   for (const auto  : ObjectPrefixMap)
-if (Path.startswith(Entry.first))
-  return (Twine(Entry.second) + Path.substr(Entry.first.size())).str();
-  return Path.str();
+if (PathRef.startswith(Entry.first))
+  return (Twine(Entry.second) + PathRef.substr(Entry.first.size())).str();
+  return Path;
 }
 
 bool DWARFLinker::registerModuleReference(
Index: clang/test/CodeGen/debug-prefix-map.c
===
--- clang/test/CodeGen/debug-prefix-map.c
+++ clang/test/CodeGen/debug-prefix-map.c
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH=empty %s -emit-llvm -o - | FileCheck %s 
-check-prefix CHECK-EVIL
 // RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -main-file-name 
debug-prefix-map.c | FileCheck %s
 // RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - 
-fdebug-compilation-dir %p | FileCheck %s -check-prefix CHECK-COMPILATION-DIR
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -isysroot %p 
-debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
 // RUN: %clang -g -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
 // RUN: %clang -g -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
 
@@ -40,3 +41,4 @@
 // CHECK-COMPILATION-DIR: !DIFile(filename: "{{.*}}", directory: 
"/UNLIKELY_PATH/empty")
 // CHECK-COMPILATION-DIR: !DIFile(filename: "{{.*}}Inputs/stdio.h", directory: 
"/UNLIKELY_PATH/empty")
 // CHECK-COMPILATION-DIR-NOT: !DIFile(filename:
+// CHECK-SYSROOT: !DICompileUnit({{.*}}sysroot: "/UNLIKELY_PATH/empty"
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -631,7 +631,7 @@
   ? llvm::DICompileUnit::DebugNameTableKind::None
   : static_cast(
 CGOpts.DebugNameTable),
-  CGOpts.DebugRangesBaseAddress, Sysroot, SDK);
+  CGOpts.DebugRangesBaseAddress, remapDIPath(Sysroot), SDK);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const BuiltinType *BT) {


Index: llvm/lib/DWARFLinker/DWARFLinker.cpp
===
--- llvm/lib/DWARFLinker/DWARFLinker.cpp
+++ llvm/lib/DWARFLinker/DWARFLinker.cpp
@@ -1914,12 +1914,13 @@
   return 0;
 }
 
-static std::string remapPath(StringRef Path,
+static std::string remapPath(std::string Path,
  const objectPrefixMap ) {
+  StringRef PathRef(Path);
   for (const auto  : ObjectPrefixMap)
-if (Path.startswith(Entry.first))
-  return (Twine(Entry.second) + Path.substr(Entry.first.size())).str();
-  return Path.str();
+if (PathRef.startswith(Entry.first))
+  return (Twine(Entry.second) + PathRef.substr(Entry.first.size())).str();
+  return Path;
 }
 
 bool DWARFLinker::registerModuleReference(
Index: clang/test/CodeGen/debug-prefix-map.c
===
--- clang/test/CodeGen/debug-prefix-map.c
+++ clang/test/CodeGen/debug-prefix-map.c
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=/UNLIKELY_PATH=empty %s -emit-llvm -o - | FileCheck %s -check-prefix CHECK-EVIL
 // RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -main-file-name debug-prefix-map.c | FileCheck %s
 // RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -fdebug-compilation-dir %p | FileCheck %s -check-prefix CHECK-COMPILATION-DIR
+// RUN: %clang_cc1 -debug-info-kind=standalone -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -isysroot %p -debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
 // RUN: %clang -g -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s -emit-llvm -o - | FileCheck %s
 // RUN: %clang -g -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s -emit-llvm -o - | 

[PATCH] D76385: Allow remapping Clang module include paths

[Adrian Prantl via Phabricator via cfe-commits]

aprantl updated this revision to Diff 251411.
aprantl added a comment.

Don't try to be too clever.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76385/new/

https://reviews.llvm.org/D76385

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/Modules/debug-info-moduleimport.m


Index: clang/test/Modules/debug-info-moduleimport.m
===
--- clang/test/Modules/debug-info-moduleimport.m
+++ clang/test/Modules/debug-info-moduleimport.m
@@ -34,9 +34,11 @@
 
 // RUN: %clang_cc1 -debug-info-kind=limited -fmodules -fimplicit-module-maps \
 // RUN:   -fmodules-cache-path=%t -fdebug-prefix-map=%t=/MODULE-CACHE \
+// RUN:   -fdebug-prefix-map=%S=/SRCDIR \
 // RUN:   -fmodule-format=obj -dwarf-ext-refs \
 // RUN:   %s -I %S/Inputs -isysroot /tmp/.. -I %t -emit-llvm -o - \
 // RUN: | FileCheck %s --check-prefix=SKEL-CHECK
+// SKEL-CHECK: includePath: "/SRCDIR/Inputs"
 // SKEL-CHECK: distinct !DICompileUnit({{.*}}file: ![[CUFILE:[0-9]+]]
 // SKEL-CHECK: ![[CUFILE]] = !DIFile({{.*}}directory: "[[COMP_DIR:.*]]"
 // SKEL-CHECK: distinct !DICompileUnit({{.*}}file: 
![[DWOFILE:[0-9]+]]{{.*}}splitDebugFilename: "/MODULE-CACHE{{.*}}dwoId
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2483,6 +2483,14 @@
 assert(StringRef(M->Name).startswith(CGM.getLangOpts().ModuleName) &&
"clang module without ASTFile must be specified by -fmodule-name");
 
+  // Return a StringRef to the remapped Path.
+  auto RemapPath = [&](std::string Path) -> std::string {
+Path = remapDIPath(Path);
+StringRef Relative(Path);
+Relative.consume_front(TheCU->getDirectory());
+return Relative.str();
+  };
+
   if (CreateSkeletonCU && IsRootModule && !Mod.getASTFile().empty()) {
 // PCH files don't have a signature field in the control block,
 // but LLVM detects skeleton CUs by looking for a non-zero DWO id.
@@ -2492,14 +2500,12 @@
 ? (uint64_t)Mod.getSignature()[1] << 32 | Mod.getSignature()[0]
 : ~1ULL;
 llvm::DIBuilder DIB(CGM.getModule());
-std::string PCM = remapDIPath(Mod.getASTFile());
-StringRef RelativePCM(PCM);
-RelativePCM.consume_front(TheCU->getDirectory());
+std::string PCM = Mod.getASTFile().str();
 DIB.createCompileUnit(
 TheCU->getSourceLanguage(),
 // TODO: Support "Source" from external AST providers?
 DIB.createFile(Mod.getModuleName(), TheCU->getDirectory()),
-TheCU->getProducer(), false, StringRef(), 0, RelativePCM,
+TheCU->getProducer(), false, StringRef(), 0, RemapPath(PCM),
 llvm::DICompileUnit::FullDebug, Signature);
 DIB.finalize();
   }
@@ -2508,9 +2514,10 @@
   IsRootModule ? nullptr
: getOrCreateModuleRef(ASTSourceDescriptor(*M->Parent),
   CreateSkeletonCU);
+  std::string IncludePath = Mod.getPath().str();
   llvm::DIModule *DIMod =
   DBuilder.createModule(Parent, Mod.getModuleName(), ConfigMacros,
-Mod.getPath());
+RemapPath(IncludePath));
   ModuleCache[M].reset(DIMod);
   return DIMod;
 }


Index: clang/test/Modules/debug-info-moduleimport.m
===
--- clang/test/Modules/debug-info-moduleimport.m
+++ clang/test/Modules/debug-info-moduleimport.m
@@ -34,9 +34,11 @@
 
 // RUN: %clang_cc1 -debug-info-kind=limited -fmodules -fimplicit-module-maps \
 // RUN:   -fmodules-cache-path=%t -fdebug-prefix-map=%t=/MODULE-CACHE \
+// RUN:   -fdebug-prefix-map=%S=/SRCDIR \
 // RUN:   -fmodule-format=obj -dwarf-ext-refs \
 // RUN:   %s -I %S/Inputs -isysroot /tmp/.. -I %t -emit-llvm -o - \
 // RUN: | FileCheck %s --check-prefix=SKEL-CHECK
+// SKEL-CHECK: includePath: "/SRCDIR/Inputs"
 // SKEL-CHECK: distinct !DICompileUnit({{.*}}file: ![[CUFILE:[0-9]+]]
 // SKEL-CHECK: ![[CUFILE]] = !DIFile({{.*}}directory: "[[COMP_DIR:.*]]"
 // SKEL-CHECK: distinct !DICompileUnit({{.*}}file: ![[DWOFILE:[0-9]+]]{{.*}}splitDebugFilename: "/MODULE-CACHE{{.*}}dwoId
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2483,6 +2483,14 @@
 assert(StringRef(M->Name).startswith(CGM.getLangOpts().ModuleName) &&
"clang module without ASTFile must be specified by -fmodule-name");
 
+  // Return a StringRef to the remapped Path.
+  auto RemapPath = [&](std::string Path) -> std::string {
+Path = remapDIPath(Path);
+StringRef Relative(Path);
+Relative.consume_front(TheCU->getDirectory());
+return Relative.str();
+  };
+
   if (CreateSkeletonCU && IsRootModule && !Mod.getASTFile().empty()) {
 // PCH files don't have a signature field in the control block,
 

[PATCH] D76130: [PPC][AIX] Implement variadic function handling in LowerFormalArguments_AIX

[Zarko Todorovski via Phabricator via cfe-commits]

ZarkoCA updated this revision to Diff 251408.
ZarkoCA marked 11 inline comments as done.
ZarkoCA added a comment.

Addressed code comments, working on adding and fixing tests for further clarity.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76130/new/

https://reviews.llvm.org/D76130

Files:
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-32.ll
  llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-64.ll

Index: llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-64.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/aix-cc-abi-va_args-64.ll
@@ -0,0 +1,316 @@
+; RUN: llc -O2 -mtriple powerpc64-ibm-aix-xcoff -stop-after=machine-cp -verify-machineinstrs < %s | \
+; RUN: FileCheck --check-prefixes=CHECK,64BIT %s
+
+; RUN: llc -O2 -verify-machineinstrs -mcpu=pwr4 -mattr=-altivec \
+; RUN:  -mtriple powerpc64-ibm-aix-xcoff < %s | \
+; RUN: FileCheck --check-prefixes=CHECKASM,ASM64PWR4 %s
+
+
+  @a = local_unnamed_addr global i32 1, align 4
+  @b = local_unnamed_addr global i32 2, align 4
+  @c = local_unnamed_addr global i32 3, align 4
+  @d = local_unnamed_addr global i32 4, align 4
+  @e = local_unnamed_addr global i32 5, align 4
+  @f = local_unnamed_addr global i32 6, align 4
+  @g = local_unnamed_addr global i32 7, align 4
+  @h = local_unnamed_addr global i32 8, align 4
+  @i = local_unnamed_addr global i32 9, align 4
+  @j = local_unnamed_addr global i32 10, align 4
+
+define signext i32 @va_arg1(i32 signext %a, ...) local_unnamed_addr {
+entry:
+  %arg = alloca i8*, align 8
+  %0 = bitcast i8** %arg to i8*
+  call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull %0)
+  call void @llvm.va_start(i8* nonnull %0)
+  %cmp7 = icmp sgt i32 %a, 0
+  br i1 %cmp7, label %for.body.preheader, label %for.end
+
+for.body.preheader:
+  %argp.cur.pre = load i8*, i8** %arg, align 8
+  %1 = add i32 %a, -1
+  %2 = zext i32 %1 to i64
+  %3 = add nuw nsw i64 %2, 1
+  %min.iters.check = icmp ult i32 %1, 8
+  br i1 %min.iters.check, label %for.body.preheader28, label %vector.memcheck
+
+vector.memcheck:
+  %uglygep = getelementptr inbounds i8, i8* %0, i64 1
+  %scevgep = getelementptr i8, i8* %argp.cur.pre, i64 4
+  %4 = shl nuw nsw i64 %2, 3
+  %5 = add nuw nsw i64 %4, 8
+  %scevgep11 = getelementptr i8, i8* %argp.cur.pre, i64 %5
+  %bound0 = icmp ugt i8* %scevgep11, %0
+  %bound1 = icmp ult i8* %scevgep, %uglygep
+  %found.conflict = and i1 %bound0, %bound1
+  br i1 %found.conflict, label %for.body.preheader28, label %vector.ph
+
+vector.ph:
+  %n.mod.vf = and i64 %3, 7
+  %6 = icmp eq i64 %n.mod.vf, 0
+  %7 = select i1 %6, i64 8, i64 %n.mod.vf
+  %n.vec = sub nsw i64 %3, %7
+  %8 = shl nsw i64 %n.vec, 3
+  %ind.end = getelementptr i8, i8* %argp.cur.pre, i64 %8
+  %ind.end13 = trunc i64 %n.vec to i32
+  %next.gep = getelementptr i8, i8* %argp.cur.pre, i64 4
+  %next.gep17 = getelementptr i8, i8* %argp.cur.pre, i64 4
+  %next.gep20 = getelementptr i8, i8* %argp.cur.pre, i64 8
+  br label %vector.body
+
+vector.body:
+  %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]
+  %vec.phi = phi <4 x i32> [ , %vector.ph ], [ %19, %vector.body ]
+  %vec.phi21 = phi <4 x i32> [ zeroinitializer, %vector.ph ], [ %20, %vector.body ]
+  %9 = shl i64 %index, 3
+  %10 = shl i64 %index, 3
+  %11 = or i64 %10, 32
+  %12 = shl i64 %index, 3
+  %13 = or i64 %12, 56
+  %14 = getelementptr inbounds i8, i8* %next.gep20, i64 %13
+  %15 = getelementptr inbounds i8, i8* %next.gep, i64 %9
+  %16 = getelementptr inbounds i8, i8* %next.gep17, i64 %11
+  %17 = bitcast i8* %15 to <8 x i32>*
+  %18 = bitcast i8* %16 to <8 x i32>*
+  %wide.vec = load <8 x i32>, <8 x i32>* %17, align 4
+  %wide.vec23 = load <8 x i32>, <8 x i32>* %18, align 4
+  %strided.vec = shufflevector <8 x i32> %wide.vec, <8 x i32> undef, <4 x i32> 
+  %strided.vec24 = shufflevector <8 x i32> %wide.vec23, <8 x i32> undef, <4 x i32> 
+  %19 = add <4 x i32> %strided.vec, %vec.phi
+  %20 = add <4 x i32> %strided.vec24, %vec.phi21
+  %index.next = add i64 %index, 8
+  %21 = icmp eq i64 %index.next, %n.vec
+  br i1 %21, label %middle.block, label %vector.body
+
+middle.block:
+  store i8* %14, i8** %arg, align 8
+  %bin.rdx = add <4 x i32> %20, %19
+  %rdx.shuf = shufflevector <4 x i32> %bin.rdx, <4 x i32> undef, <4 x i32> 
+  %bin.rdx25 = add <4 x i32> %bin.rdx, %rdx.shuf
+  %rdx.shuf26 = shufflevector <4 x i32> %bin.rdx25, <4 x i32> undef, <4 x i32> 
+  %bin.rdx27 = add <4 x i32> %bin.rdx25, %rdx.shuf26
+  %22 = extractelement <4 x i32> %bin.rdx27, i32 0
+  br label %for.body.preheader28
+
+for.body.preheader28:
+  %argp.cur.ph = phi i8* [ %argp.cur.pre, %vector.memcheck ], [ %argp.cur.pre, %for.body.preheader ], [ %ind.end, %middle.block ]
+  %total.09.ph = phi i32 [ undef, %vector.memcheck ], [ undef, %for.body.preheader ], [ %22, %middle.block ]
+  %i.08.ph = phi i32 [ 0, %vector.memcheck ], [ 0, %for.body.preheader ], [ 

[PATCH] D76396: Allow immediate invocation of constructors

[Wyatt Childers via Phabricator via cfe-commits]

wchilders abandoned this revision.
wchilders added a comment.

In D76396#1930773 , @Tyker wrote:

> I have already a patch aiming to do the same thing. D74007 
> 


Oof, okay, sounds good. I was not aware of this patch, it looks to be much 
further along :)

>> Provide improvements which allow the cached values of ConstantExpr to be 
>> used by both the constant evaluator and code gen
> 
> this is definitely something we should do.
> 
>> Update the application of evaluation contexts, using the stronger guarantees 
>> of manifest constant evaluation to apply the ConstantEvaluated evaluation 
>> context in more places
> 
> the tracking of evaluation context isn't as good as it could/should.

With this being closed out in favor of Tyker's patch, I'll post a patch for 
reusing cached values of ConstantExpr shortly.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76396/new/

https://reviews.llvm.org/D76396



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76360: [PPC][AIX] Emit correct Vaarg for 32BIT-AIX in clang

[Zarko Todorovski via Phabricator via cfe-commits]

ZarkoCA marked 8 inline comments as done.
ZarkoCA added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4175
 namespace {
 /// PPC32_SVR4_ABIInfo - The 32-bit PowerPC ELF (SVR4) ABI information.
 class PPC32_SVR4_ABIInfo : public DefaultABIInfo {

sfertile wrote:
> This name and comment is misleading, the class is used for both SVR4 and 
> Darwin, and after this patch AIX. We need to fix the name comment to reflect 
> that.
Does this wording of the comment work? 



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4232
   QualType Ty) const {
-  if (getTarget().getTriple().isOSDarwin()) {
+  // TODO: Add AIX ABI Info.  Currently we are relying on PPC32_SVR4_ABIInfo to
+  // emit correct VAArg.

hubert.reinterpretcast wrote:
> No need for two spaces. Add comma after "Currently".
Thanks, I've found it hard to shake the habits my Grade 8 typing teacher taught 
me. 



Comment at: clang/test/CodeGen/aix-vararg.c:4
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -emit-llvm -o - %s | 
FileCheck %s --check-prefix=32BIT
+#include 
+

hubert.reinterpretcast wrote:
> Can we use built-in types and functions in place of a header inclusion?
I'm worried about legal/copyright issues with using contents from AIX system 
headers to LLVM testcases. But I can do that for sure once I understand what I 
am allowed to do.   



Comment at: clang/test/CodeGen/aix-vararg.c:10
+  va_arg(arg, int);
+  va_end(arg);
+}

jasonliu wrote:
> As part of a "va_..." family, do we also want to test va_copy? 
Good suggestion, added. 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76360/new/

https://reviews.llvm.org/D76360



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73307: Unique Names for Functions with Internal Linkage

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram updated this revision to Diff 251409.
tmsriram marked 2 inline comments as done.
tmsriram added a comment.

Address reviewer comments.  Fix test and delete blank line.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73307/new/

https://reviews.llvm.org/D73307

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/unique-internal-funcnames.c
  clang/test/Driver/funique-internal-funcnames.c

Index: clang/test/Driver/funique-internal-funcnames.c
===
--- /dev/null
+++ clang/test/Driver/funique-internal-funcnames.c
@@ -0,0 +1,4 @@
+// RUN: %clang -### -funique-internal-funcnames %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -funique-internal-funcnames -fno-unique-internal-funcnames %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// CHECK-OPT: "-funique-internal-funcnames"
+// CHECK-NOOPT-NOT: {{-funique-internal-funcnames}}
Index: clang/test/CodeGen/unique-internal-funcnames.c
===
--- /dev/null
+++ clang/test/CodeGen/unique-internal-funcnames.c
@@ -0,0 +1,16 @@
+// REQUIRES: x86-registered-target
+
+// RUN: %clang -target x86_64 -S -o - %s | FileCheck %s --check-prefix=PLAIN
+// RUN: %clang -target x86_64 -S -funique-internal-funcnames -o -  %s | FileCheck %s --check-prefix=UNIQUE
+
+static int foo() {
+  return 0;
+}
+
+int (*bar())() {
+  return foo;
+}
+
+// PLAIN: foo:
+// UNIQUE-NOT: foo:
+// UNIQUE: foo.{{[0-9a-f]+}}:
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -958,6 +958,7 @@
   Opts.StackSizeSection = Args.hasArg(OPT_fstack_size_section);
   Opts.UniqueSectionNames = !Args.hasArg(OPT_fno_unique_section_names);

+  Opts.UniqueInternalFuncNames = Args.hasArg(OPT_funique_internal_funcnames);
   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
 
   Opts.NoUseJumpTables = Args.hasArg(OPT_fno_jump_tables);
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1124,6 +1124,23 @@
   const auto *ND = cast(GD.getDecl());
   std::string MangledName = getMangledNameImpl(*this, GD, ND);
 
+  // With option -funique-internal-funcnames, functions with internal linkage
+  // should get unique names.  Use the hash of module name to get a unique
+  // identifier and this is a best effort.
+  if (getCodeGenOpts().UniqueInternalFuncNames &&
+  dyn_cast(GD.getDecl()) &&
+  getFunctionLinkage(GD) == llvm::GlobalValue::InternalLinkage &&
+  !getModule().getSourceFileName().empty()) {
+llvm::MD5 Md5;
+Md5.update(getModule().getSourceFileName());
+llvm::MD5::MD5Result R;
+Md5.final(R);
+SmallString<32> Str;
+llvm::MD5::stringifyResult(R, Str);
+std::string UniqueSuffix = ("." + Str).str();
+MangledName += UniqueSuffix;
+  }
+
   // Ensure either we have different ABIs between host and device compilations,
   // says host compilation following MSVC ABI but device compilation follows
   // Itanium C++ ABI or, if they follow the same ABI, kernel names after
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4222,6 +4222,8 @@
 options::OPT_fno_function_sections,
 options::OPT_fdata_sections,
 options::OPT_fno_data_sections,
+options::OPT_funique_internal_funcnames,
+options::OPT_fno_unique_internal_funcnames,
 options::OPT_funique_section_names,
 options::OPT_fno_unique_section_names,
 options::OPT_mrestrict_it,
@@ -4819,6 +4821,10 @@
 options::OPT_fno_unique_section_names, true))
 CmdArgs.push_back("-fno-unique-section-names");
 
+  if (Args.hasFlag(options::OPT_funique_internal_funcnames,
+   options::OPT_fno_unique_internal_funcnames, false))
+CmdArgs.push_back("-funique-internal-funcnames");
+
   Args.AddLastArg(CmdArgs, options::OPT_finstrument_functions,
   options::OPT_finstrument_functions_after_inlining,
   options::OPT_finstrument_function_entry_bare);
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1971,6 +1971,12 @@
 def fno_unique_section_names : Flag <["-"], "fno-unique-section-names">,
   Group, Flags<[CC1Option]>;
 
+def funique_internal_funcnames : Flag <["-"], 

[PATCH] D76360: [PPC][AIX] Emit correct Vaarg for 32BIT-AIX in clang

[Zarko Todorovski via Phabricator via cfe-commits]

ZarkoCA updated this revision to Diff 251407.
ZarkoCA marked 3 inline comments as done.
ZarkoCA added a comment.

Changed comments per suggestions. 
Added `va_copy` in test case.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76360/new/

https://reviews.llvm.org/D76360

Files:
  clang/lib/Basic/Targets/PPC.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/aix-vararg.c


Index: clang/test/CodeGen/aix-vararg.c
===
--- /dev/null
+++ clang/test/CodeGen/aix-vararg.c
@@ -0,0 +1,40 @@
+// REQUIRES: powerpc-registered-target
+// REQUIRES: asserts
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -emit-llvm -o - %s | 
FileCheck %s --check-prefix=32BIT
+#include 
+
+void aix_varg(int a, ...) {
+  va_list arg;
+  va_start(arg, a);
+  va_list arg2;
+  va_arg(arg, int);
+  va_copy(arg2, arg);
+  va_end(arg);
+  va_end(arg2);
+}
+
+// 32BIT:   define void @aix_varg(i32 %a, ...) #0 {
+// 32BIT-NEXT:  entry:
+// 32BIT-NEXT:%a.addr = alloca i32, align 4
+// 32BIT-NEXT:%arg = alloca i8*, align 4
+// 32BIT-NEXT:%arg2 = alloca i8*, align 4
+// 32BIT-NEXT:store i32 %a, i32* %a.addr, align 4
+// 32BIT-NEXT:%arg1 = bitcast i8** %arg to i8*
+// 32BIT-NEXT:call void @llvm.va_start(i8* %arg1)
+// 32BIT-NEXT:%argp.cur = load i8*, i8** %arg, align 4
+// 32BIT-NEXT:%argp.next = getelementptr inbounds i8, i8* %argp.cur, i32 4
+// 32BIT-NEXT:store i8* %argp.next, i8** %arg, align 4
+// 32BIT-NEXT:%0 = bitcast i8* %argp.cur to i32*
+// 32BIT-NEXT:%1 = load i32, i32* %0, align 4
+// 32BIT-NEXT:%2 = bitcast i8** %arg2 to i8*
+// 32BIT-NEXT:%3 = bitcast i8** %arg to i8*
+// 32BIT-NEXT:call void @llvm.va_copy(i8* %2, i8* %3)
+// 32BIT-NEXT:%arg3 = bitcast i8** %arg to i8*
+// 32BIT-NEXT:call void @llvm.va_end(i8* %arg3)
+// 32BIT-NEXT:%arg24 = bitcast i8** %arg2 to i8*
+// 32BIT-NEXT:call void @llvm.va_end(i8* %arg24)
+// 32BIT-NEXT:ret void
+// 32BIT-NEXT:  }
+// 32BIT: declare void @llvm.va_start(i8*) #1
+// 32BIT: declare void @llvm.va_copy(i8*, i8*) #1
+// 32BIT: declare void @llvm.va_end(i8*) #1
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -4172,7 +4172,8 @@
 
 // PowerPC-32
 namespace {
-/// PPC32_SVR4_ABIInfo - The 32-bit PowerPC ELF (SVR4) ABI information.
+/// PPC32_SVR4_ABIInfo - The 32-bit PowerPC ABI information, used by PowerPC 
ELF
+/// (SVR4), Darwin and AIX.
 class PPC32_SVR4_ABIInfo : public DefaultABIInfo {
   bool IsSoftFloatABI;
 
@@ -4229,7 +4230,10 @@
 // DefaultABIInfo::EmitVAArg.
 Address PPC32_SVR4_ABIInfo::EmitVAArg(CodeGenFunction , Address VAList,
   QualType Ty) const {
-  if (getTarget().getTriple().isOSDarwin()) {
+  // TODO: Add AIX ABI Info. Currently, we are relying on PPC32_SVR4_ABIInfo to
+  // emit correct VAArg.
+  if (getTarget().getTriple().isOSDarwin() ||
+  getTarget().getTriple().isOSAIX()) {
 auto TI = getContext().getTypeInfoInChars(Ty);
 TI.second = getParamTypeAlignment(Ty);
 
Index: clang/lib/Basic/Targets/PPC.h
===
--- clang/lib/Basic/Targets/PPC.h
+++ clang/lib/Basic/Targets/PPC.h
@@ -369,7 +369,8 @@
   }
 
   BuiltinVaListKind getBuiltinVaListKind() const override {
-// This is the ELF definition, and is overridden by the Darwin sub-target
+// This is the ELF definition, and is overridden by the Darwin and AIX
+// sub-targets.
 return TargetInfo::PowerABIBuiltinVaList;
   }
 };


Index: clang/test/CodeGen/aix-vararg.c
===
--- /dev/null
+++ clang/test/CodeGen/aix-vararg.c
@@ -0,0 +1,40 @@
+// REQUIRES: powerpc-registered-target
+// REQUIRES: asserts
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -emit-llvm -o - %s | FileCheck %s --check-prefix=32BIT
+#include 
+
+void aix_varg(int a, ...) {
+  va_list arg;
+  va_start(arg, a);
+  va_list arg2;
+  va_arg(arg, int);
+  va_copy(arg2, arg);
+  va_end(arg);
+  va_end(arg2);
+}
+
+// 32BIT:   define void @aix_varg(i32 %a, ...) #0 {
+// 32BIT-NEXT:  entry:
+// 32BIT-NEXT:%a.addr = alloca i32, align 4
+// 32BIT-NEXT:%arg = alloca i8*, align 4
+// 32BIT-NEXT:%arg2 = alloca i8*, align 4
+// 32BIT-NEXT:store i32 %a, i32* %a.addr, align 4
+// 32BIT-NEXT:%arg1 = bitcast i8** %arg to i8*
+// 32BIT-NEXT:call void @llvm.va_start(i8* %arg1)
+// 32BIT-NEXT:%argp.cur = load i8*, i8** %arg, align 4
+// 32BIT-NEXT:%argp.next = getelementptr inbounds i8, i8* %argp.cur, i32 4
+// 32BIT-NEXT:store i8* %argp.next, i8** %arg, align 4
+// 32BIT-NEXT:%0 = bitcast i8* %argp.cur to i32*
+// 32BIT-NEXT:%1 = load i32, i32* %0, align 4
+// 32BIT-NEXT:%2 = bitcast i8** %arg2 to i8*
+// 32BIT-NEXT:%3 = bitcast 

[PATCH] D76418: [Syntax] Build template declaration nodes

[Dmitri Gribenko via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG88bf9b3d26f0: [Syntax] Build template declaration nodes 
(authored by hlopko, committed by gribozavr).

Changed prior to commit:
  https://reviews.llvm.org/D76418?vs=251304=251404#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76418/new/

https://reviews.llvm.org/D76418

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/unittests/Tooling/Syntax/TreeTest.cpp

Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -99,6 +99,7 @@
   Diags->setClient(new IgnoringDiagConsumer);
 // Prepare to run a compiler.
 std::vector Args = {"syntax-test", "-std=c++11",
+  "-fno-delayed-template-parsing",
   "-fsyntax-only", FileName};
 Invocation = createInvocationFromCommandLine(Args, Diags, FS);
 assert(Invocation);
@@ -678,6 +679,212 @@
   `-;
 )txt"},
   {R"cpp(
+template  struct cls {};
+template  int var = 10;
+template  int fun() {}
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-cls
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-int
+|   |-SimpleDeclarator
+|   | |-var
+|   | |-=
+|   | `-UnknownExpression
+|   |   `-10
+|   `-;
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-int
+|-SimpleDeclarator
+| |-fun
+| `-ParametersAndQualifiers
+|   |-(
+|   `-)
+`-CompoundStatement
+  |-{
+  `-}
+)txt"},
+  {R"cpp(
+template 
+struct X {
+  template 
+  U foo();
+};
+)cpp",
+   R"txt(
+*: TranslationUnit
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-struct
+|-X
+|-{
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-U
+| |->
+| `-SimpleDeclaration
+|   |-U
+|   |-SimpleDeclarator
+|   | |-foo
+|   | `-ParametersAndQualifiers
+|   |   |-(
+|   |   `-)
+|   `-;
+|-}
+`-;
+)txt"},
+  {R"cpp(
+template  struct X {};
+template  struct X {};
+template <> struct X {};
+
+template struct X;
+extern template struct X;
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-T
+|   |-*
+|   |->
+|   |-{
+|   |-}
+|   `-;
+|-TemplateDeclaration
+| |-template
+| |-<
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-int
+|   |->
+|   |-{
+|   |-}
+|   `-;
+|-ExplicitTemplateInstantiation
+| |-template
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-<
+|   |-double
+|   |->
+|   `-;
+`-ExplicitTemplateInstantiation
+  |-extern
+  |-template
+  `-SimpleDeclaration
+|-struct
+|-X
+|-<
+|-float
+|->
+`-;
+)txt"},
+  {R"cpp(
+template  struct X { struct Y; };
+template  struct X::Y {};
+)cpp",
+   R"txt(
+*: TranslationUnit
+|-TemplateDeclaration
+| |-template
+| |-<
+| |-UnknownDeclaration
+| | |-class
+| | `-T
+| |->
+| `-SimpleDeclaration
+|   |-struct
+|   |-X
+|   |-{
+|   |-SimpleDeclaration
+|   | |-struct
+|   | |-Y
+|   | `-;
+|   |-}
+|   `-;
+`-TemplateDeclaration
+  |-template
+  |-<
+  |-UnknownDeclaration
+  | |-class
+  | `-T
+  |->
+  `-SimpleDeclaration
+|-struct
+|-X
+|-<
+|-T
+|->
+|-::
+|-Y
+|-{
+|-}
+`-;
+   )txt"},
+  {R"cpp(
 namespace ns {}
 using namespace ::ns;
 )cpp",
@@ -726,7 +933,7 @@
 )cpp",
R"txt(
 *: TranslationUnit
-`-UnknownDeclaration
+`-TemplateDeclaration
   |-template
   |-<
   |-UnknownDeclaration
Index: clang/lib/Tooling/Syntax/Nodes.cpp
===
--- clang/lib/Tooling/Syntax/Nodes.cpp
+++ clang/lib/Tooling/Syntax/Nodes.cpp
@@ -58,6 +58,10 @@
 return OS << "LinkageSpecificationDeclaration";
   case NodeKind::SimpleDeclaration:
 return OS << "SimpleDeclaration";
+  case NodeKind::TemplateDeclaration:
+return OS << "TemplateDeclaration";
+  case 

[clang] 88bf9b3 - [Syntax] Build template declaration nodes

[Dmitri Gribenko via cfe-commits]

Author: Marcel Hlopko
Date: 2020-03-19T17:43:07+01:00
New Revision: 88bf9b3d26f06eaf33972d1f371edc4cb187ff1a

URL: 
https://github.com/llvm/llvm-project/commit/88bf9b3d26f06eaf33972d1f371edc4cb187ff1a
DIFF: 
https://github.com/llvm/llvm-project/commit/88bf9b3d26f06eaf33972d1f371edc4cb187ff1a.diff

LOG: [Syntax] Build template declaration nodes

Summary:
Rollforward of
https://reviews.llvm.org/rGdd12826808f9079e164b82e64b0697a077379241 after
temporarily adding -fno-delayed-template-parsing to the TreeTest.

Original summary:

> Copy of https://reviews.llvm.org/D72334, submitting with Ilya's permission.
>
> Handles template declaration of all kinds.
>
> Also builds template declaration nodes for specializations and explicit
> instantiations of classes.
>
> Some missing things will be addressed in the follow-up patches:
>
> * specializations of functions and variables,
> * template parameters.

Reviewers: gribozavr2

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Tooling/Syntax/Nodes.h
clang/lib/Tooling/Syntax/BuildTree.cpp
clang/lib/Tooling/Syntax/Nodes.cpp
clang/unittests/Tooling/Syntax/TreeTest.cpp

Removed: 




diff  --git a/clang/include/clang/Tooling/Syntax/Nodes.h 
b/clang/include/clang/Tooling/Syntax/Nodes.h
index 82fcac33f99b..f4d482bb848c 100644
--- a/clang/include/clang/Tooling/Syntax/Nodes.h
+++ b/clang/include/clang/Tooling/Syntax/Nodes.h
@@ -64,6 +64,8 @@ enum class NodeKind : uint16_t {
   StaticAssertDeclaration,
   LinkageSpecificationDeclaration,
   SimpleDeclaration,
+  TemplateDeclaration,
+  ExplicitTemplateInstantiation,
   NamespaceDefinition,
   NamespaceAliasDefinition,
   UsingNamespaceDirective,
@@ -112,6 +114,9 @@ enum class NodeRole : uint8_t {
   StaticAssertDeclaration_condition,
   StaticAssertDeclaration_message,
   SimpleDeclaration_declarator,
+  TemplateDeclaration_declaration,
+  ExplicitTemplateInstantiation_externKeyword,
+  ExplicitTemplateInstantiation_declaration,
   ArraySubscript_sizeExpression,
   TrailingReturnType_arrow,
   TrailingReturnType_declarator,
@@ -396,6 +401,34 @@ class SimpleDeclaration final : public Declaration {
   std::vector declarators();
 };
 
+/// template  
+class TemplateDeclaration final : public Declaration {
+public:
+  TemplateDeclaration() : Declaration(NodeKind::TemplateDeclaration) {}
+  static bool classof(const Node *N) {
+return N->kind() == NodeKind::TemplateDeclaration;
+  }
+  syntax::Leaf *templateKeyword();
+  syntax::Declaration *declaration();
+};
+
+/// template 
+/// Examples:
+/// template struct X
+/// template void foo()
+/// template int var
+class ExplicitTemplateInstantiation final : public Declaration {
+public:
+  ExplicitTemplateInstantiation()
+  : Declaration(NodeKind::ExplicitTemplateInstantiation) {}
+  static bool classof(const Node *N) {
+return N->kind() == NodeKind::ExplicitTemplateInstantiation;
+  }
+  syntax::Leaf *templateKeyword();
+  syntax::Leaf *externKeyword();
+  syntax::Declaration *declaration();
+};
+
 /// namespace  {  }
 class NamespaceDefinition final : public Declaration {
 public:

diff  --git a/clang/lib/Tooling/Syntax/BuildTree.cpp 
b/clang/lib/Tooling/Syntax/BuildTree.cpp
index 9ebf7d29d8ed..a09ac1c53e34 100644
--- a/clang/lib/Tooling/Syntax/BuildTree.cpp
+++ b/clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -18,6 +18,7 @@
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
+#include "clang/Basic/Specifiers.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Lex/Lexer.h"
 #include "clang/Tooling/Syntax/Nodes.h"
@@ -189,7 +190,6 @@ class syntax::TreeBuilder {
   /// Should be called for expressions in non-statement position to avoid
   /// wrapping into expression statement.
   void markExprChild(Expr *Child, NodeRole Role);
-
   /// Set role for a token starting at \p Loc.
   void markChildToken(SourceLocation Loc, NodeRole R);
   /// Set role for \p T.
@@ -199,6 +199,9 @@ class syntax::TreeBuilder {
   void markChild(llvm::ArrayRef Range, NodeRole R);
   /// Set role for the delayed node that spans exactly \p Range.
   void markDelayedChild(llvm::ArrayRef Range, NodeRole R);
+  /// Set role for the node that may or may not be delayed. Node must span
+  /// exactly \p Range.
+  void markMaybeDelayedChild(llvm::ArrayRef Range, NodeRole R);
 
   /// Finish building the tree and consume the root node.
   syntax::TranslationUnit *finalize() && {
@@ -215,6 +218,9 @@ class syntax::TreeBuilder {
 return TU;
   }
 
+  /// Finds a token starting at \p L. The token must exist if \p L is valid.
+  const syntax::Token *findToken(SourceLocation L) const;
+
   /// getRange() finds the syntax tokens corresponding to the passed source
   /// locations.
   /// \p First is the start position of the first token and \p Last is 

[PATCH] D74918: Add method to TargetInfo to get CPU cache line size

[Zoe Carver via Phabricator via cfe-commits]

zoecarver marked 3 inline comments as done.
zoecarver added a comment.

@lebedev.ri LLVM may be better, I'm not sure. If you feel strongly I can move 
it.

@jyknight I'm planning on adding a builtin that uses this method. I can put the 
patch up for that first if you would like.




Comment at: clang/include/clang/Basic/TargetInfo.h:1192
+  // Get the cache line size of a given cpu. This method switches over
+  // the given cpu and returns `0` if the CPU is not found.
+  virtual Optional getCPUCacheLineSize() const { return None; }

lebedev.ri wrote:
> Comment is no longer valid - returns `None` instead.
> Also, might it be worth explicitly calling out that there is zero guarantees 
> of stability of the returned values?
Good catch. I think we should try to have as much stability as possible but I 
can add a note that these values may change. 



Comment at: clang/lib/Basic/Targets/X86.cpp:1786
+// i386
+case CK_i386:
+// Netburst

craig.topper wrote:
> I found the documentation for the 82385 cache controller chip for the 386. 
> It's a bit weird. The tags for the cache are based on 16 byte lines, but 
> there are valid bits for every 2 bytes within that line. So its possible for 
> only a portion of a line to be valid.
Interesting. Does this mean that we should be returning a different value?



Comment at: clang/lib/Basic/Targets/X86.cpp:1840
+// Core
+case CK_Core2:
+case CK_Generic:

craig.topper wrote:
> If Yonah and Penryn are 64, then Core2 should be as well. It's the generation 
> between them.
I'll update it. Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74918/new/

https://reviews.llvm.org/D74918



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D76433: [Syntax] Make TreeTest independent from the host platform.

[Marcel Hlopko via Phabricator via cfe-commits]

hlopko updated this revision to Diff 251399.
hlopko added a comment.

Reformat


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76433/new/

https://reviews.llvm.org/D76433

Files:
  clang/unittests/Tooling/Syntax/TreeTest.cpp


Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -99,6 +99,9 @@
   Diags->setClient(new IgnoringDiagConsumer);
 // Prepare to run a compiler.
 std::vector Args = {"syntax-test", "-std=c++11",
+  // Hard-setting target so the unit test
+  // behavior doesn't depend on the host.
+  "-target", "x86_64-unknown-unknown",
   "-fsyntax-only", FileName};
 Invocation = createInvocationFromCommandLine(Args, Diags, FS);
 assert(Invocation);


Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -99,6 +99,9 @@
   Diags->setClient(new IgnoringDiagConsumer);
 // Prepare to run a compiler.
 std::vector Args = {"syntax-test", "-std=c++11",
+  // Hard-setting target so the unit test
+  // behavior doesn't depend on the host.
+  "-target", "x86_64-unknown-unknown",
   "-fsyntax-only", FileName};
 Invocation = createInvocationFromCommandLine(Args, Diags, FS);
 assert(Invocation);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D69330: [AST] Add RecoveryExpr to retain expressions on semantic errors

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

all prerequisite patches have been landed, it is time to land this patch now. 
Would be nice to have a second look before committing it +@sammccall.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69330/new/

https://reviews.llvm.org/D69330



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits