[PATCH] D159213: [AIX][ClangRepl] Disable new tests on AIX

2023-08-30 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision.
shchenz added a comment.

LGTM. Thanks for fixing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159213

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


[PATCH] D156076: [PowerPC][Clang] Remove constraint for initial-exec TLS mode on AIX

2023-08-30 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156076

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


[PATCH] D156344: Disable call to fma for soft-float

2023-08-15 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

In D156344#4583767 , @long5hot wrote:

> In D156344#4583559 , @shchenz wrote:
>
>> compiler-rt builtins library should not just undefining fma for PPC, right 
>> (see 
>> https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html)? If 
>> so, maybe we should at least first try not generating fma for soft-float at 
>> the first place where fmul + fadd is fused, like `tryEmitFMulAdd` in clang 
>> front end?
>
> I actually raised D154605  for that one, 
> but it's only for X86.
> I was relying on target-features containing "+fma", which is wrong. The 
> review was raised just to get feedback from community working on various 
> targets.
> Plan is to disable fma-intrinsic from IR for all targets which doesn't 
> support fma.

Thanks. I think `soft-float` looks like a candidate for the `hasFMA` function 
in D154605 .


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

https://reviews.llvm.org/D156344

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


[PATCH] D156344: Disable call to fma for soft-float

2023-08-13 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

compiler-rt builtins library should not just undefining fma for PPC, right (see 
https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html)? If so, 
maybe we should at least first try not generating fma for soft-float at the 
first place where fmul + fadd is fused, like `tryEmitFMulAdd` in clang front 
end?


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

https://reviews.llvm.org/D156344

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


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-07-09 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

> What is left for this to be reverted, in the quest to fully enable IAS for 
> AIX?

See `XCOFFAsmParser::ParseDirectiveCSect()` and I think qual symbol names in 
AIX assembly(quite common for AIX assembly) can also not be parsed with llvm's 
asm parser.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

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


[PATCH] D152924: [libLTO][AIX] Respect `-f[no]-integrated-as` on AIX

2023-06-15 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Seems passing `-Wl,-bplugin_opt:-no-integrated-as=1` from clang driver does not 
work as expected. Is this expected or by design(We can only use 
-fno-integrated-as but no -Wl,-bplugin_opt:-no-integrated-as=1)?

  clang -flto -Wl,-bplugin_opt:-no-integrated-as=1 *.c -v
-bplugin_opt:-no-integrated-as=1 -bplugin:../lib/libLTO.so 
-bplugin_opt:-mcpu=pwr7 -bplugin_opt:-no-integrated-as=0 ;;; Note the second 
-no-integrated-as=0 pass from clang front-end.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152924

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


[PATCH] D152924: [libLTO][AIX] Respect `-f[no]-integrated-as` on AIX

2023-06-15 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:700
+CmdArgs.push_back(Args.MakeArgString(
+Twine(PluginOptPrefix) + "-no-integrated-as=" + NoIntegratedAs));
+  else if (!UseIntegratedAs) {

qiongsiwu1 wrote:
> shchenz wrote:
> > qiongsiwu1 wrote:
> > > shchenz wrote:
> > > > Seems other options leverage the default value in the back end, for 
> > > > example the default value for `DisableIntegratedAS` in backend is 
> > > > false, so when the front end requires integrated-as, maybe we can save 
> > > > the option here?
> > > Ah thanks for the comment! 
> > > 
> > > > maybe we can save the option here?
> > > 
> > > Could you help me understand what we mean by "the option"? Do we mean 
> > > saving (or using?) the value of `-f[no]-integrated-as` explicitly here 
> > > somehow instead of relying on `ToolChain.useIntegratedAs()`? How do we 
> > > intend to use the saved option value? My understanding is that 
> > > `DisableIntegratedAS` takes its value from the option `-no-integrated-as` 
> > > if `-no-integrated-as` is specified. As pointed out eariler, 
> > > `DisableIntegratedAS` is false by default. This code explicitly sets 
> > > `-no-integrated-as` to `0` or `1`, so for the LTO use case, we overwrite 
> > > the back end default since the option is always present. 
> > For example, if front-end requires to use integrated-assembler which is 
> > same with back-end's default value, we don't need to pass 
> > `-no-integrated-as=0`? We only pass the option `-no-integrated-as=1` when 
> > `if (IsOSAIX && !UseIntegratedAs)`.
> Ah I see! Thanks for the clarification! 
> 
> @w2yehia and I discussed this and we preferred setting the option explicitly 
> regardless of the backend's default. The reason was that we did not want to 
> leave a hanging case where the option was not passed to the backend, a case 
> in which we would rely on a non-local option(`DisableIntegratedAS`)'s default 
> value to control the backend. In other words, always passing in the option 
> allowed us to reason about this code locally within this file. @w2yehia feel 
> free to chime in if I am not describing our discussion correctly. 
> 
> Could you help me understand the benefit of not passing in the option for the 
> default case? 
> Could you help me understand the benefit of not passing in the option for the 
> default case?

Too many options pass from front-end to back-end is a reason. And another 
reason is: I met one case that there is a back-end option has no default value, 
so each front-end, like clang and FORTRAN will have to explicitly pass the same 
option. I was asked to set a default in the back-end, so no need to explicitly 
set the options in each front-end.

If what I read is right, some bool type options like `EmulatedTLS`, 
`EnableStackSizeSection` are only passed when their values are not the same 
with the back-end's default.

I am ok to keep it as now if you guys already have an agreement. This is just 
minor I think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152924

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


[PATCH] D152924: [libLTO][AIX] Respect `-f[no]-integrated-as` on AIX

2023-06-15 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:700
+CmdArgs.push_back(Args.MakeArgString(
+Twine(PluginOptPrefix) + "-no-integrated-as=" + NoIntegratedAs));
+  else if (!UseIntegratedAs) {

qiongsiwu1 wrote:
> shchenz wrote:
> > Seems other options leverage the default value in the back end, for example 
> > the default value for `DisableIntegratedAS` in backend is false, so when 
> > the front end requires integrated-as, maybe we can save the option here?
> Ah thanks for the comment! 
> 
> > maybe we can save the option here?
> 
> Could you help me understand what we mean by "the option"? Do we mean saving 
> (or using?) the value of `-f[no]-integrated-as` explicitly here somehow 
> instead of relying on `ToolChain.useIntegratedAs()`? How do we intend to use 
> the saved option value? My understanding is that `DisableIntegratedAS` takes 
> its value from the option `-no-integrated-as` if `-no-integrated-as` is 
> specified. As pointed out eariler, `DisableIntegratedAS` is false by default. 
> This code explicitly sets `-no-integrated-as` to `0` or `1`, so for the LTO 
> use case, we overwrite the back end default since the option is always 
> present. 
For example, if front-end requires to use integrated-assembler which is same 
with back-end's default value, we don't need to pass `-no-integrated-as=0`? We 
only pass the option `-no-integrated-as=1` when `if (IsOSAIX && 
!UseIntegratedAs)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152924

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


[PATCH] D152924: [libLTO][AIX] Respect `-f[no]-integrated-as` on AIX

2023-06-14 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

@qiongsiwu1 Hi, thanks for the patch. Almost good to me, except one small nit.




Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:700
+CmdArgs.push_back(Args.MakeArgString(
+Twine(PluginOptPrefix) + "-no-integrated-as=" + NoIntegratedAs));
+  else if (!UseIntegratedAs) {

Seems other options leverage the default value in the back end, for example the 
default value for `DisableIntegratedAS` in backend is false, so when the front 
end requires integrated-as, maybe we can save the option here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152924

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


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-06-04 Thread ChenZheng via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4b27ad735c8d: [AIX] use system assembler for assembly files 
(authored by shchenz).

Changed prior to commit:
  https://reviews.llvm.org/D148490?vs=521233=528257#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/aix-as.c


Index: clang/test/Driver/aix-as.c
===
--- clang/test/Driver/aix-as.c
+++ clang/test/Driver/aix-as.c
@@ -1,22 +1,40 @@
 // General tests that as(1) invocations on AIX targets are sane. Note that we
 // only test assembler functionalities in this suite.
 
+// Check powerpc-ibm-aix7.1.0.0, system assembler is used for assembly files, 
32-bit.
+// RUN: %clang -x assembler %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefix=CHECK-AS32 %s
+//
+// RUN: %clang -x assembler %s -### -c 2>&1 -fno-integrated-as \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefix=CHECK-AS32 %s
+
 // Check powerpc-ibm-aix7.1.0.0, 32-bit.
 // RUN: %clang %s -### -c 2>&1 \
 // RUN: --target=powerpc-ibm-aix7.1.0.0 \
-// RUN:   | FileCheck --check-prefix=CHECK-AS32 %s
+// RUN:   | FileCheck --check-prefixes=CHECK-AS32,CHECK-AS32-CC1 %s
 // CHECK-AS32-NOT: warning:
-// CHECK-AS32: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
+// CHECK-AS32-CC1: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
 // CHECK-AS32: "{{.*}}as{{(.exe)?}}" 
 // CHECK-AS32: "-a32" 
 // CHECK-AS32: "-many" 
 
+// Check powerpc64-ibm-aix7.1.0.0, system assembler is used for assembly 
files, 64-bit.
+// RUN: %clang -x assembler %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefix=CHECK-AS64 %s
+//
+// RUN: %clang -x assembler %s -### -c -fno-integrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefix=CHECK-AS64 %s
+
 // Check powerpc64-ibm-aix7.1.0.0, 64-bit.
 // RUN: %clang %s -### -c 2>&1 \
 // RUN: --target=powerpc64-ibm-aix7.1.0.0 \
-// RUN:   | FileCheck --check-prefix=CHECK-AS64 %s
+// RUN:   | FileCheck --check-prefixes=CHECK-AS64,CHECK-AS64-CC1 %s
 // CHECK-AS64-NOT: warning:
-// CHECK-AS64: "-cc1" "-triple" "powerpc64-ibm-aix7.1.0.0"
+// CHECK-AS64-CC1: "-cc1" "-triple" "powerpc64-ibm-aix7.1.0.0"
 // CHECK-AS64: "{{.*}}as{{(.exe)?}}" 
 // CHECK-AS64: "-a64" 
 // CHECK-AS64: "-many"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -662,7 +662,8 @@
   if (D.IsFlangMode() && getDriver().ShouldUseFlangCompiler(JA)) return 
getFlang();
   if (getDriver().ShouldUseClangCompiler(JA)) return getClang();
   Action::ActionClass AC = JA.getKind();
-  if (AC == Action::AssembleJobClass && useIntegratedAs())
+  if (AC == Action::AssembleJobClass && useIntegratedAs() &&
+  !getTriple().isOSAIX())
 return getClangAs();
   return getTool(AC);
 }


Index: clang/test/Driver/aix-as.c
===
--- clang/test/Driver/aix-as.c
+++ clang/test/Driver/aix-as.c
@@ -1,22 +1,40 @@
 // General tests that as(1) invocations on AIX targets are sane. Note that we
 // only test assembler functionalities in this suite.
 
+// Check powerpc-ibm-aix7.1.0.0, system assembler is used for assembly files, 32-bit.
+// RUN: %clang -x assembler %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefix=CHECK-AS32 %s
+//
+// RUN: %clang -x assembler %s -### -c 2>&1 -fno-integrated-as \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefix=CHECK-AS32 %s
+
 // Check powerpc-ibm-aix7.1.0.0, 32-bit.
 // RUN: %clang %s -### -c 2>&1 \
 // RUN: --target=powerpc-ibm-aix7.1.0.0 \
-// RUN:   | FileCheck --check-prefix=CHECK-AS32 %s
+// RUN:   | FileCheck --check-prefixes=CHECK-AS32,CHECK-AS32-CC1 %s
 // CHECK-AS32-NOT: warning:
-// CHECK-AS32: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
+// CHECK-AS32-CC1: "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
 // CHECK-AS32: "{{.*}}as{{(.exe)?}}" 
 // CHECK-AS32: "-a32" 
 // CHECK-AS32: "-many" 
 
+// Check powerpc64-ibm-aix7.1.0.0, system assembler is used for assembly files, 64-bit.
+// RUN: %clang -x assembler %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefix=CHECK-AS64 %s
+//
+// RUN: %clang -x assembler %s -### -c -fno-integrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefix=CHECK-AS64 %s
+
 // Check powerpc64-ibm-aix7.1.0.0, 64-bit.
 // RUN: %clang %s -### -c 2>&1 \
 // RUN: 

[PATCH] D148490: [AIX] use system assembler for assembly files

2023-06-01 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/test/Driver/target-as.s:1
 // Make sure the -march is passed down to cc1as.
 // RUN: %clang -target i386-unknown-freebsd -### -c -integrated-as %s \

MaskRay wrote:
> shchenz wrote:
> > MaskRay wrote:
> > > aix-as.c will be more appropriate.
> > Do you mean we change this file to `aix-as.s` or we change back to previous 
> > version? The file `target-as.s` can not be renamed to `aix-as.s`, it also 
> > contains tests for i386, see the first run line.
> You can add the new tests to the existing `aix-as.s`. The behavior is about 
> assemblers on AIX. `aix-as.s` seems more appropriate than `target-as.s`.
hmm, we want to use assembly file for test. There is aix-as.c but no aix-as.s.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

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


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-05-31 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/test/Driver/target-as.s:1
 // Make sure the -march is passed down to cc1as.
 // RUN: %clang -target i386-unknown-freebsd -### -c -integrated-as %s \

MaskRay wrote:
> aix-as.c will be more appropriate.
Do you mean we change this file to `aix-as.s` or we change back to previous 
version? The file `target-as.s` can not be renamed to `aix-as.s`, it also 
contains tests for i386, see the first run line.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

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


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-05-29 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

gentle ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

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


[PATCH] D150758: [AIX] make integrated-as as default on AIX.

2023-05-17 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: llvm/lib/MC/MCAsmInfoXCOFF.cpp:55
   HasDotTypeDotSizeDirective = false;
-  UseIntegratedAssembler = false;
+  UseIntegratedAssembler = true;
   ParseInlineAsmUsingAsmParser = true;

brad wrote:
> Instead of setting the value to true you can just remove the line all 
> together.
+1

And maybe this default value change can be put into another patch, as this is 
for backend?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150758

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


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-05-11 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

> I am not sure you need 6 RUN lines to test this. Whether a target uses 
> integrated assembler has an existing test file and you can reuse that.

I don't have strong prefer which one we should use, a new file or reuse file. 
Since you point out, I change to reuse a legacy one in same dir. Please notice 
that there are some other targets that has their own assembler test file, like 
mips-as.s, systemz-as.s, arm64-as.s.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

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


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-05-11 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 521233.
shchenz added a comment.

update tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/target-as.s


Index: clang/test/Driver/target-as.s
===
--- clang/test/Driver/target-as.s
+++ clang/test/Driver/target-as.s
@@ -1,6 +1,29 @@
 // Make sure the -march is passed down to cc1as.
 // RUN: %clang -target i386-unknown-freebsd -### -c -integrated-as %s \
-// RUN: -march=geode 2>&1 | FileCheck -check-prefix=TARGET %s
+// RUN: -march=geode 2>&1 | FileCheck -check-prefix=GEODE %s
+
+// Check powerpc64-ibm-aix7.1.0.0, 64-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AIX-AS64,CHECK %s
 //
-// TARGET: "-cc1as"
-// TARGET: "-target-cpu" "geode"
+// RUN: %clang %s -### -c -fno-integrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AIX-AS64,CHECK %s
+
+// Check powerpc-ibm-aix7.1.0.0, 32-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AIX-AS32,CHECK %s
+//
+// RUN: %clang %s -### -c 2>&1 -fno-integrated-as \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AIX-AS32,CHECK %s
+
+// GEODE: "-cc1as"
+// GEODE: "-target-cpu" "geode"
+
+// CHECK: "{{.*}}as{{(.exe)?}}"
+// AIX-AS32: "-a32"
+// AIX-AS64: "-a64"
+// CHECK: "-many"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -662,7 +662,8 @@
   if (D.IsFlangMode() && getDriver().ShouldUseFlangCompiler(JA)) return 
getFlang();
   if (getDriver().ShouldUseClangCompiler(JA)) return getClang();
   Action::ActionClass AC = JA.getKind();
-  if (AC == Action::AssembleJobClass && useIntegratedAs())
+  if (AC == Action::AssembleJobClass && useIntegratedAs() &&
+  !getTriple().isOSAIX())
 return getClangAs();
   return getTool(AC);
 }


Index: clang/test/Driver/target-as.s
===
--- clang/test/Driver/target-as.s
+++ clang/test/Driver/target-as.s
@@ -1,6 +1,29 @@
 // Make sure the -march is passed down to cc1as.
 // RUN: %clang -target i386-unknown-freebsd -### -c -integrated-as %s \
-// RUN: -march=geode 2>&1 | FileCheck -check-prefix=TARGET %s
+// RUN: -march=geode 2>&1 | FileCheck -check-prefix=GEODE %s
+
+// Check powerpc64-ibm-aix7.1.0.0, 64-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AIX-AS64,CHECK %s
 //
-// TARGET: "-cc1as"
-// TARGET: "-target-cpu" "geode"
+// RUN: %clang %s -### -c -fno-integrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AIX-AS64,CHECK %s
+
+// Check powerpc-ibm-aix7.1.0.0, 32-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AIX-AS32,CHECK %s
+//
+// RUN: %clang %s -### -c 2>&1 -fno-integrated-as \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AIX-AS32,CHECK %s
+
+// GEODE: "-cc1as"
+// GEODE: "-target-cpu" "geode"
+
+// CHECK: "{{.*}}as{{(.exe)?}}"
+// AIX-AS32: "-a32"
+// AIX-AS64: "-a64"
+// CHECK: "-many"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -662,7 +662,8 @@
   if (D.IsFlangMode() && getDriver().ShouldUseFlangCompiler(JA)) return getFlang();
   if (getDriver().ShouldUseClangCompiler(JA)) return getClang();
   Action::ActionClass AC = JA.getKind();
-  if (AC == Action::AssembleJobClass && useIntegratedAs())
+  if (AC == Action::AssembleJobClass && useIntegratedAs() &&
+  !getTriple().isOSAIX())
 return getClangAs();
   return getTool(AC);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-05-10 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

gentle ping...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

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


[PATCH] D150181: [XCOFF][DWARF] XCOFF64 should be able to select the dwarf version under intergrated-as mode.

2023-05-10 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.
This revision is now accepted and ready to land.

I think this is correct. DWARF spec indicates that DWARF64 should not be set as 
default. So it is right to change to DWARF32 by default for integrated-as mode 
for XCOFF64.

LGTM with one nit.




Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:403
+  ((TT.isOSBinFormatELF() ||
+(TT.isOSBinFormatXCOFF() && UseIntegratedAs)) &&
+   (Asm->TM.Options.MCOptions.Dwarf64 || MMI->getModule()->isDwarf64())) ||

Nit: Maybe we can use a variable to contain the value for 
`TT.isOSBinFormatXCOFF()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150181

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


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-05-03 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

gentle ping...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

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


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-04-25 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 517011.
shchenz added a comment.

address @qiucf comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/aix-assembler.s


Index: clang/test/Driver/aix-assembler.s
===
--- /dev/null
+++ clang/test/Driver/aix-assembler.s
@@ -0,0 +1,30 @@
+// Check powerpc64-ibm-aix7.1.0.0, 64-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// RUN: %clang %s -### -c -fno-integrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// Check powerpc-ibm-aix7.1.0.0, 32-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 -fno-integrated-as \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// CHECK: "{{.*}}as{{(.exe)?}}"
+// AS32: "-a32"
+// AS64: "-a64"
+// CHECK: "-many"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -662,7 +662,8 @@
   if (D.IsFlangMode() && getDriver().ShouldUseFlangCompiler(JA)) return 
getFlang();
   if (getDriver().ShouldUseClangCompiler(JA)) return getClang();
   Action::ActionClass AC = JA.getKind();
-  if (AC == Action::AssembleJobClass && useIntegratedAs())
+  if (AC == Action::AssembleJobClass && useIntegratedAs() &&
+  !getTriple().isOSAIX())
 return getClangAs();
   return getTool(AC);
 }


Index: clang/test/Driver/aix-assembler.s
===
--- /dev/null
+++ clang/test/Driver/aix-assembler.s
@@ -0,0 +1,30 @@
+// Check powerpc64-ibm-aix7.1.0.0, 64-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// RUN: %clang %s -### -c -fno-integrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// Check powerpc-ibm-aix7.1.0.0, 32-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 -fno-integrated-as \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// CHECK: "{{.*}}as{{(.exe)?}}"
+// AS32: "-a32"
+// AS64: "-a64"
+// CHECK: "-many"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -662,7 +662,8 @@
   if (D.IsFlangMode() && getDriver().ShouldUseFlangCompiler(JA)) return getFlang();
   if (getDriver().ShouldUseClangCompiler(JA)) return getClang();
   Action::ActionClass AC = JA.getKind();
-  if (AC == Action::AssembleJobClass && useIntegratedAs())
+  if (AC == Action::AssembleJobClass && useIntegratedAs() &&
+  !getTriple().isOSAIX())
 return getClangAs();
   return getTool(AC);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-04-23 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

gentle ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148490

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


[PATCH] D148490: [AIX] use system assembler for assembly files

2023-04-16 Thread ChenZheng via Phabricator via cfe-commits
shchenz created this revision.
shchenz added reviewers: hubert.reinterpretcast, nemanjai, PowerPC.
shchenz added a project: LLVM.
Herald added a project: All.
shchenz requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Change to system assembler to compile assembly files even `-fintegrated-as` is 
specified.
We don't have a good Clang as for now for assembly files on AIX.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148490

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/lib/Driver/ToolChains/AIX.h
  clang/test/Driver/aix-assembler.s


Index: clang/test/Driver/aix-assembler.s
===
--- /dev/null
+++ clang/test/Driver/aix-assembler.s
@@ -0,0 +1,31 @@
+
+// Check powerpc64-ibm-aix7.1.0.0, 64-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// RUN: %clang %s -### -c -fno-integrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// Check powerpc-ibm-aix7.1.0.0, 32-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 -fno-integrated-as \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// CHECK: "{{.*}}as{{(.exe)?}}"
+// AS32: "-a32"
+// AS64: "-a64"
+// CHECK: "-many"
Index: clang/lib/Driver/ToolChains/AIX.h
===
--- clang/lib/Driver/ToolChains/AIX.h
+++ clang/lib/Driver/ToolChains/AIX.h
@@ -97,8 +97,10 @@
 protected:
   Tool *buildAssembler() const override;
   Tool *buildLinker() const override;
+  Tool *getTool(Action::ActionClass AC) const override;
 
 private:
+  mutable std::unique_ptr Assembler;
   llvm::StringRef GetHeaderSysroot(const llvm::opt::ArgList ) const;
   bool ParseInlineAsmUsingAsmParser;
 };
Index: clang/lib/Driver/ToolChains/AIX.cpp
===
--- clang/lib/Driver/ToolChains/AIX.cpp
+++ clang/lib/Driver/ToolChains/AIX.cpp
@@ -416,6 +416,19 @@
   return ToolChain::RLT_CompilerRT;
 }
 
+Tool *AIX::getTool(Action::ActionClass AC) const {
+  switch (AC) {
+  default:
+break;
+  // AIX always uses system assembler to compile assembly files.
+  case Action::AssembleJobClass:
+if (!Assembler)
+  Assembler.reset(buildAssembler());
+return Assembler.get();
+  }
+  return ToolChain::getTool(AC);
+}
+
 auto AIX::buildAssembler() const -> Tool * { return new aix::Assembler(*this); 
}
 
 auto AIX::buildLinker() const -> Tool * { return new aix::Linker(*this); }
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -662,7 +662,8 @@
   if (D.IsFlangMode() && getDriver().ShouldUseFlangCompiler(JA)) return 
getFlang();
   if (getDriver().ShouldUseClangCompiler(JA)) return getClang();
   Action::ActionClass AC = JA.getKind();
-  if (AC == Action::AssembleJobClass && useIntegratedAs())
+  if (AC == Action::AssembleJobClass && useIntegratedAs() &&
+  !getTriple().isOSAIX())
 return getClangAs();
   return getTool(AC);
 }


Index: clang/test/Driver/aix-assembler.s
===
--- /dev/null
+++ clang/test/Driver/aix-assembler.s
@@ -0,0 +1,31 @@
+
+// Check powerpc64-ibm-aix7.1.0.0, 64-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// RUN: %clang %s -### -c -fno-integrated-as 2>&1 \
+// RUN: --target=powerpc64-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS64,CHECK %s
+
+// Check powerpc-ibm-aix7.1.0.0, 32-bit.
+// RUN: %clang %s -### -c -fintegrated-as 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// RUN: %clang %s -### -c 2>&1 -fno-integrated-as \
+// RUN: --target=powerpc-ibm-aix7.1.0.0 \
+// RUN:   | FileCheck --check-prefixes=AS32,CHECK %s
+
+// CHECK: 

[PATCH] D143467: [PowerPC] Add target feature requirement to builtins

2023-03-09 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

I think this is a good direction. For example we can avoid the crash in 
https://github.com/llvm/llvm-project/issues/60959 and give a clear diagnostic 
message.

However, manually adding the required target feature seems a little mistakable, 
like the one below. I guess we can not get the required feature in the LLVM 
instruction TDs(if the builtin is mapped to a IR intrinsic and the intrinsic is 
selected inside the instruction TD) because this is done in CLANG? 
Really need to way to make sure that the instruction are marked with the 
accurate target feature, if not possible to do this inside the compiler, an 
offline script maybe? Checking the instruction one by one is a little 
time-consuming.




Comment at: clang/include/clang/Basic/BuiltinsPPC.def:491
+TARGET_BUILTIN(__builtin_altivec_vabsduh, "V8UsV8UsV8Us", "", "altivec")
+TARGET_BUILTIN(__builtin_altivec_vabsduw, "V4UiV4UiV4Ui", "", "altivec")
 

These builtins `vabsdub`, `vabsduh`, `vabsduw`  should require ISA3.0 which is 
not altivec or vsx. Do we have a reasonable feature for Power9 instructions, 
`power9-vector` maybe?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143467

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


[PATCH] D140544: [DebugInfo] make DW_LANG_C11 respect -gstrict-dwarf

2022-12-25 Thread ChenZheng via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
shchenz marked an inline comment as done.
Closed by commit rGb1d7010caa43: [DebugInfo] make DW_LANG_C11 respect 
-gstrict-dwarf (authored by shchenz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140544

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-info-programming-language.c


Index: clang/test/CodeGen/debug-info-programming-language.c
===
--- clang/test/CodeGen/debug-info-programming-language.c
+++ clang/test/CodeGen/debug-info-programming-language.c
@@ -4,7 +4,14 @@
 // RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
 // RUN:   -x c -std=c17 -O0 -disable-llvm-passes -debug-info-kind=limited \
 // RUN:   | FileCheck --check-prefix=CHECK-C17 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-STRICT %s
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-C11 %s
 
+// CHECK-STRICT: !DICompileUnit(language: DW_LANG_C99
 // CHECK-C11: !DICompileUnit(language: DW_LANG_C11
 // Update this check once support for DW_LANG_C17 is broadly supported/known in
 // consumers. Maybe we'll skip this and go to the DWARFv6 language+version
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -578,8 +578,8 @@
 LangTag = llvm::dwarf::DW_LANG_OpenCL;
   } else if (LO.RenderScript) {
 LangTag = llvm::dwarf::DW_LANG_GOOGLE_RenderScript;
-  } else if (LO.C11) {
-LangTag = llvm::dwarf::DW_LANG_C11;
+  } else if (LO.C11 && !(CGO.DebugStrictDwarf && CGO.DwarfVersion < 5)) {
+  LangTag = llvm::dwarf::DW_LANG_C11;
   } else if (LO.C99) {
 LangTag = llvm::dwarf::DW_LANG_C99;
   } else {


Index: clang/test/CodeGen/debug-info-programming-language.c
===
--- clang/test/CodeGen/debug-info-programming-language.c
+++ clang/test/CodeGen/debug-info-programming-language.c
@@ -4,7 +4,14 @@
 // RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s -o - \
 // RUN:   -x c -std=c17 -O0 -disable-llvm-passes -debug-info-kind=limited \
 // RUN:   | FileCheck --check-prefix=CHECK-C17 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-STRICT %s
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-C11 %s
 
+// CHECK-STRICT: !DICompileUnit(language: DW_LANG_C99
 // CHECK-C11: !DICompileUnit(language: DW_LANG_C11
 // Update this check once support for DW_LANG_C17 is broadly supported/known in
 // consumers. Maybe we'll skip this and go to the DWARFv6 language+version
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -578,8 +578,8 @@
 LangTag = llvm::dwarf::DW_LANG_OpenCL;
   } else if (LO.RenderScript) {
 LangTag = llvm::dwarf::DW_LANG_GOOGLE_RenderScript;
-  } else if (LO.C11) {
-LangTag = llvm::dwarf::DW_LANG_C11;
+  } else if (LO.C11 && !(CGO.DebugStrictDwarf && CGO.DwarfVersion < 5)) {
+  LangTag = llvm::dwarf::DW_LANG_C11;
   } else if (LO.C99) {
 LangTag = llvm::dwarf::DW_LANG_C99;
   } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D140544: [DebugInfo] make DW_LANG_C11 respect -gstrict-dwarf

2022-12-22 Thread ChenZheng via Phabricator via cfe-commits
shchenz marked an inline comment as done.
shchenz added inline comments.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:582
   } else if (LO.C11) {
-LangTag = llvm::dwarf::DW_LANG_C11;
+if (CGO.DebugStrictDwarf && CGO.DwarfVersion < 5)
+  LangTag = llvm::dwarf::DW_LANG_C;

dblaikie wrote:
> Generally, I think, we downgrade to the nearest/highest version? (for 
> instance today when the user requests C17, they get C11, not C - and when 
> they request C++17 they get C_plus_plus_14, not plain C_plus_plus) I see 
> there's the same choice up in the C++ case too, but not sure it's the right 
> one?
> 
> Should probably do the same thing for strict dwarf, and emit this as C99?
> 
Fair enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140544

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


[PATCH] D140544: [DebugInfo] make DW_LANG_C11 respect -gstrict-dwarf

2022-12-22 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 484994.
shchenz added a comment.

address @dblaikie comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140544

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-info-programming-language.c


Index: clang/test/CodeGen/debug-info-programming-language.c
===
--- clang/test/CodeGen/debug-info-programming-language.c
+++ clang/test/CodeGen/debug-info-programming-language.c
@@ -4,7 +4,14 @@
 // RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
 // RUN:   -x c -std=c17 -O0 -disable-llvm-passes -debug-info-kind=limited \
 // RUN:   | FileCheck --check-prefix=CHECK-C17 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-STRICT %s
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-C11 %s
 
+// CHECK-STRICT: !DICompileUnit(language: DW_LANG_C99
 // CHECK-C11: !DICompileUnit(language: DW_LANG_C11
 // Update this check once support for DW_LANG_C17 is broadly supported/known in
 // consumers. Maybe we'll skip this and go to the DWARFv6 language+version
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -578,8 +578,8 @@
 LangTag = llvm::dwarf::DW_LANG_OpenCL;
   } else if (LO.RenderScript) {
 LangTag = llvm::dwarf::DW_LANG_GOOGLE_RenderScript;
-  } else if (LO.C11) {
-LangTag = llvm::dwarf::DW_LANG_C11;
+  } else if (LO.C11 && !(CGO.DebugStrictDwarf && CGO.DwarfVersion < 5)) {
+  LangTag = llvm::dwarf::DW_LANG_C11;
   } else if (LO.C99) {
 LangTag = llvm::dwarf::DW_LANG_C99;
   } else {


Index: clang/test/CodeGen/debug-info-programming-language.c
===
--- clang/test/CodeGen/debug-info-programming-language.c
+++ clang/test/CodeGen/debug-info-programming-language.c
@@ -4,7 +4,14 @@
 // RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s -o - \
 // RUN:   -x c -std=c17 -O0 -disable-llvm-passes -debug-info-kind=limited \
 // RUN:   | FileCheck --check-prefix=CHECK-C17 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-STRICT %s
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-C11 %s
 
+// CHECK-STRICT: !DICompileUnit(language: DW_LANG_C99
 // CHECK-C11: !DICompileUnit(language: DW_LANG_C11
 // Update this check once support for DW_LANG_C17 is broadly supported/known in
 // consumers. Maybe we'll skip this and go to the DWARFv6 language+version
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -578,8 +578,8 @@
 LangTag = llvm::dwarf::DW_LANG_OpenCL;
   } else if (LO.RenderScript) {
 LangTag = llvm::dwarf::DW_LANG_GOOGLE_RenderScript;
-  } else if (LO.C11) {
-LangTag = llvm::dwarf::DW_LANG_C11;
+  } else if (LO.C11 && !(CGO.DebugStrictDwarf && CGO.DwarfVersion < 5)) {
+  LangTag = llvm::dwarf::DW_LANG_C11;
   } else if (LO.C99) {
 LangTag = llvm::dwarf::DW_LANG_C99;
   } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D140544: [DebugInfo] make DW_LANG_C11 respect -gstrict-dwarf

2022-12-22 Thread ChenZheng via Phabricator via cfe-commits
shchenz created this revision.
shchenz added reviewers: dblaikie, probinson, aprantl.
shchenz added a project: LLVM.
Herald added a project: All.
shchenz requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D140544

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/debug-info-programming-language.c


Index: clang/test/CodeGen/debug-info-programming-language.c
===
--- clang/test/CodeGen/debug-info-programming-language.c
+++ clang/test/CodeGen/debug-info-programming-language.c
@@ -4,7 +4,14 @@
 // RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
 // RUN:   -x c -std=c17 -O0 -disable-llvm-passes -debug-info-kind=limited \
 // RUN:   | FileCheck --check-prefix=CHECK-C17 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-STRICT %s
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-C11 %s
 
+// CHECK-STRICT: !DICompileUnit(language: DW_LANG_C,
 // CHECK-C11: !DICompileUnit(language: DW_LANG_C11
 // Update this check once support for DW_LANG_C17 is broadly supported/known in
 // consumers. Maybe we'll skip this and go to the DWARFv6 language+version
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -579,7 +579,10 @@
   } else if (LO.RenderScript) {
 LangTag = llvm::dwarf::DW_LANG_GOOGLE_RenderScript;
   } else if (LO.C11) {
-LangTag = llvm::dwarf::DW_LANG_C11;
+if (CGO.DebugStrictDwarf && CGO.DwarfVersion < 5)
+  LangTag = llvm::dwarf::DW_LANG_C;
+else
+  LangTag = llvm::dwarf::DW_LANG_C11;
   } else if (LO.C99) {
 LangTag = llvm::dwarf::DW_LANG_C99;
   } else {


Index: clang/test/CodeGen/debug-info-programming-language.c
===
--- clang/test/CodeGen/debug-info-programming-language.c
+++ clang/test/CodeGen/debug-info-programming-language.c
@@ -4,7 +4,14 @@
 // RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s -o - \
 // RUN:   -x c -std=c17 -O0 -disable-llvm-passes -debug-info-kind=limited \
 // RUN:   | FileCheck --check-prefix=CHECK-C17 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-STRICT %s
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c -std=c11 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   -gstrict-dwarf | FileCheck --check-prefix=CHECK-C11 %s
 
+// CHECK-STRICT: !DICompileUnit(language: DW_LANG_C,
 // CHECK-C11: !DICompileUnit(language: DW_LANG_C11
 // Update this check once support for DW_LANG_C17 is broadly supported/known in
 // consumers. Maybe we'll skip this and go to the DWARFv6 language+version
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -579,7 +579,10 @@
   } else if (LO.RenderScript) {
 LangTag = llvm::dwarf::DW_LANG_GOOGLE_RenderScript;
   } else if (LO.C11) {
-LangTag = llvm::dwarf::DW_LANG_C11;
+if (CGO.DebugStrictDwarf && CGO.DwarfVersion < 5)
+  LangTag = llvm::dwarf::DW_LANG_C;
+else
+  LangTag = llvm::dwarf::DW_LANG_C11;
   } else if (LO.C99) {
 LangTag = llvm::dwarf::DW_LANG_C99;
   } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138105: [PowerPC] Support test data class intrinsic of 128-bit float

2022-12-05 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138105

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


[PATCH] D138105: [PowerPC] Support test data class intrinsic of 128-bit float

2022-11-20 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

The error message needs to be updated too:

  def err_ppc_invalid_test_data_class_type : Error<
"expected a 'float' or 'double' for the first argument">;

And can we add a test case for ibm float128 in the clang?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138105

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


[PATCH] D136187: [clang][AIX] Omitting Explicit Debugger Tuning Option

2022-10-19 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM except one minor in the testcase.

Thanks for adding this improvement.




Comment at: clang/test/Driver/debug-options.c:121
 // RUN: %clang -### -c -g %s -target powerpc-ibm-aix-xcoff 2>&1 \
-// RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_DBX %s
+// RUN: | FileCheck -check-prefix=G_LIMITED %s
 // RUN: %clang -### -c -g %s -target powerpc64-ibm-aix-xcoff 2>&1 \

nit: we can check that no `-debugger-tuning=` is emitted by check `G_NOTUNING`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136187

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


[PATCH] D136187: [clang][AIX] Omitting Explicit Debugger Tuning Option

2022-10-18 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Driver/ToolChains/AIX.h:91
   llvm::DebuggerKind getDefaultDebuggerTuning() const override {
-return llvm::DebuggerKind::DBX;
+return llvm::DebuggerKind::Default;
   }

This sounds not right. Omitting `-debugger-tuning=dbx` does not mean we will 
change the default tuning  debugger on AIX, right? i.e. DBX is still the 
default debugger on AIX no matter in the clang fe or llvm be.

We should just be able to do some customization when we call 
`RenderDebugEnablingArgs` for AIX in 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Clang.cpp#L4367-L4368


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136187

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


[PATCH] D135908: [clang][LTO] Setting Desired Default AIX Debugging Options

2022-10-17 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks.




Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:588
+else if (A->getOption().matches(options::OPT_ggdb) ||
+ Args.getLastArg(options::OPT_ggdbN_Group))
   CmdArgs.push_back(

nit: maybe we don't need to change this. `OPT_gTune_Group` will check the four 
debugger types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135908

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


[PATCH] D135908: [clang][LTO] Setting Desired Default AIX Debugging Options

2022-10-13 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:589
+  // On platforms other than AIX, gdb is the default option.
+  // On AIX, dbx will be automatically pick up in the presense of the
+  // debugger tuning argument, so set gdb only if it is specified.

Typo: presense -> absence?



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:590
+  // On AIX, dbx will be automatically pick up in the presense of the
+  // debugger tuning argument, so set gdb only if it is specified.
+  if (!IsOSAIX || A->getOption().matches(options::OPT_ggdb) ||

Could you also post another patch to fix the no-lto path to remove the 
redundant `-debugger-tuning=dbx` on AIX? We should make the lto mode and 
non-lto mode be consistent.



Comment at: clang/test/Driver/lto-aix.c:8
+//
+// Test debugging options
+// RUN: %clang -target powerpc-ibm-aix-xcoff -### %s -flto -g 2>&1 \

Can we add case that by default, no `-debugger-tune` is emitted?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135908

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


[PATCH] D133488: [clang][PowerPC][NFC] Add base test case for PPC64 VAArg aggregate smaller than a slot

2022-10-13 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133488

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


[PATCH] D131953: [PowerPC][Coroutines] Add tail-call check with context information for coroutines

2022-08-18 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.

This LGTM. Although `supportsTailCallFor` is not completely equal to how PPC 
backend checks tail call support, we can continuously improve this when we have 
more caller of `supportsTailCallFor()` in future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131953

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


[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

2022-08-09 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:10744
+Store = DAG.getStore(
+Op->getOperand(0), DL,
+DAG.getNode(ISD::XOR, DL, VT, Load, DAG.getAllOnesConstant(DL, VT)),

Nit: Maybe we need to set the chain input for store as the chain output of the 
load.

`Op->getOperand(0)` -> `Load->getValue(1)`

There is data dependency between the load and the store, so above change will 
not impact the correctness. But that makes more sense from memory access order 
part.



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:190
+; CHECK-FAST-NEXT:addi r4, r1, 120
+; CHECK-FAST-NEXT:stdx r3, r4, r5
+; CHECK-FAST-NEXT:ld r3, -28688(r13)

We may need to check why we are not storing `not r3, r3` directly to `120(r1)` 
at -O0, like `std r3, 120(r1)`. Seems now we are storing to `119(r1)`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129016

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


[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

2022-07-29 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/test/CodeGen/PowerPC/builtins-ppc-stackprotect.c:11
+// RUN:  FileCheck %s
+// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | \

nit: do we need -O2?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:10702
+
+// If SafeStack or !StackProtector, kill_canary is not supported.
+if (MF.getFunction().hasFnAttribute(Attribute::SafeStack) ||

Is it possible to handle this when we generate `Intrinsic::ppc_kill_canary`, 
for example in the FE? Passing and handling this useless intrinsic in all the 
opt passes should be avoided?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:10718
+// before corruption, so we XOR the canary word with all 1 bits.
+const uint64_t XORWord = 0x;
+

nit: we may don't need this magic number here, we can use 
`DAG.getAllOnesConstant()` when we generate the `XOR` below?



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:5
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux \
+; RUN:   --ppc-asm-full-reg-names < %s | FileCheck %s -check-prefix=LINUX
+

+1, we should add a RUN line for  64bit Linux LE for 
`-mtriple=powerpc64le-unknown-linux-gnu`

and for 32-bit AIX too.



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:21
+
+attributes #0 = { sspreq }
+; Function Attrs: sspreq

nit: we may can add `nounwind` attribute to the function to remove the 
unnecessary `cfi` related instructions in the test.



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:34
+; AIX-NEXT:not r4, r4
+; AIX-NEXT:std r4, 0(r3)
+; AIX-NEXT:ld r3, 0(r3)

The functionality here seems wrong, AFAIK, we should overwrite the content in 
the slack slot instead of the data csect. Which means the store here should be 
`std r4, 120(r1)` instead of `std r4, 0(r3)`. Stack protection aims to check 
that the stack content is not changed unexpectedly.



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:59
+; LINUX-NEXT:not r3, r3
+; LINUX-NEXT:std r3, 120(r1)
+; LINUX-NEXT:ld r3, 120(r1)

Linux seems right...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129016

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


[PATCH] D127189: [clang][AIX] Add option to control quadword lock free atomics ABI on AIX

2022-07-25 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127189

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


[PATCH] D127189: [clang][AIX] Add option to control quadword lock free atomics ABI on AIX

2022-07-24 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/include/clang/Driver/Options.td:3611
   HelpText<"Enable the default Altivec ABI on AIX (AIX only). Uses only 
volatile vector registers.">;
+def maix_quadword_atomics : Flag<["-"], "maix64-quadword-atomics">,
+  Group, Flags<[CC1Option]>,

lkail wrote:
> shchenz wrote:
> > lkail wrote:
> > > shchenz wrote:
> > > > amyk wrote:
> > > > > Would it be better if we called this `maix64-quadword-atomics` 
> > > > > instead? 
> > > > Do we need to change the backend check below too?
> > > > ```
> > > > bool PPCTargetLowering::shouldInlineQuadwordAtomics() const {
> > > >   // TODO: 16-byte atomic type support for AIX is in progress; we 
> > > > should be able
> > > >   // to inline 16-byte atomic ops on AIX too in the future.
> > > >   return Subtarget.isPPC64() &&
> > > >  (EnableQuadwordAtomics || 
> > > > !Subtarget.getTargetTriple().isOSAIX()) &&
> > > >  Subtarget.hasQuadwordAtomics();
> > > > }
> > > > ```
> > > We don't need to change this yet. When we are compiling a quadword lock 
> > > free libatomic, we use options `-mabi=quadword-atomics -mllvm 
> > > -ppc-quadword-atomics` to enforce generating quadword lock-free code on 
> > > AIX.
> > This makes me confuse. We need to two different options to control the 
> > frontend and backend behavior?
> > 
> > Is it the final usage? Or we will add a follow up patch to map the backend 
> > one to the FE one? IMO finally we only need the driver option 
> > `-mabi=quadword-atomics` to control the final code generation for 128 bit 
> > atomic operations, right?
> > This makes me confuse. We need to two different options to control the 
> > frontend and backend behavior?
> 
> This is multi-lang support consideration. clang is not the only frontend we 
> have using LLVM as backend on AIX. If other language frontend generates 
> `store atomic i128, ...`, the backend is supposed to generate libcalls into 
> libatomic currently.
> 
> > Is it the final usage?
> No. We finally want to achieve `-mabi=quadword-atomics` by default and 
> generate inline atomic code for cpu above pwr7 by default(no need to take OS 
> into consideration).
I know what you mean. But I assume the driver option `-mabi=quadword-atomics` 
will impact the assembly instead of just impact the frontend, right? Using 
`-mllvm` option is not right as the final solution.

There are some driver options example, like `-gstrict-dwarf`, Frontend can 
control the backend behavior and the backend can also change this option by 
`-strict-dwarf`.

Could you please explain:
1: how the backend will handle `-mabi=quadword-atomics` in future?
2: on what condition, we can start to remove below TODOs:
```
bool PPCTargetLowering::shouldInlineQuadwordAtomics() const {
// TODO: 16-byte atomic type support for AIX is in progress;
}
```

```
PPC64TargetInfo::setMaxAtomicWidth() {
// TODO: We should allow AIX to inline quadword atomics in the future.
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127189

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


[PATCH] D127189: [clang][AIX] Add option to control quadword lock free atomics ABI on AIX

2022-07-24 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Thanks for the explanation. I am more clear now about the background.




Comment at: clang/include/clang/Driver/Options.td:3611
   HelpText<"Enable the default Altivec ABI on AIX (AIX only). Uses only 
volatile vector registers.">;
+def maix_quadword_atomics : Flag<["-"], "maix64-quadword-atomics">,
+  Group, Flags<[CC1Option]>,

lkail wrote:
> shchenz wrote:
> > amyk wrote:
> > > Would it be better if we called this `maix64-quadword-atomics` instead? 
> > Do we need to change the backend check below too?
> > ```
> > bool PPCTargetLowering::shouldInlineQuadwordAtomics() const {
> >   // TODO: 16-byte atomic type support for AIX is in progress; we should be 
> > able
> >   // to inline 16-byte atomic ops on AIX too in the future.
> >   return Subtarget.isPPC64() &&
> >  (EnableQuadwordAtomics || !Subtarget.getTargetTriple().isOSAIX()) 
> > &&
> >  Subtarget.hasQuadwordAtomics();
> > }
> > ```
> We don't need to change this yet. When we are compiling a quadword lock free 
> libatomic, we use options `-mabi=quadword-atomics -mllvm 
> -ppc-quadword-atomics` to enforce generating quadword lock-free code on AIX.
This makes me confuse. We need to two different options to control the frontend 
and backend behavior?

Is it the final usage? Or we will add a follow up patch to map the backend one 
to the FE one? IMO finally we only need the driver option 
`-mabi=quadword-atomics` to control the final code generation for 128 bit 
atomic operations, right?



Comment at: clang/lib/Basic/Targets/PPC.cpp:854
+  HasQuadwordAtomics)
+MaxAtomicInlineWidth = 128;
 }

lkail wrote:
> shchenz wrote:
> > Can we set `MaxAtomicInlineWidth` in 
> > `PPC64TargetInfo::setMaxAtomicWidth()`? There is a `TODO` there
> The `TODO` marks our roadmap towards enabling quardword lock free atomics on 
> AIX too. Putting adjustment here is implementation reason: we don't context 
> of `LanguageOptions` in `PPC64TargetInfo::PPC64TargetInfo`.
OK, fair enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127189

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


[PATCH] D127189: [clang][AIX] Add option to control quadword lock free atomics ABI on AIX

2022-07-21 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Can we use the feature bit `FeatureQuadwordAtomic` to decide whether QuadAtomic 
is supported or not on AIX? Like what we do for Linux.

The reason we need this option is: we may need to compile a lock free libatomic 
on a Power7 or below target? If so, do we have similar issue on Linux? Thanks.




Comment at: clang/include/clang/Driver/Options.td:3611
   HelpText<"Enable the default Altivec ABI on AIX (AIX only). Uses only 
volatile vector registers.">;
+def maix_quadword_atomics : Flag<["-"], "maix64-quadword-atomics">,
+  Group, Flags<[CC1Option]>,

amyk wrote:
> Would it be better if we called this `maix64-quadword-atomics` instead? 
Do we need to change the backend check below too?
```
bool PPCTargetLowering::shouldInlineQuadwordAtomics() const {
  // TODO: 16-byte atomic type support for AIX is in progress; we should be able
  // to inline 16-byte atomic ops on AIX too in the future.
  return Subtarget.isPPC64() &&
 (EnableQuadwordAtomics || !Subtarget.getTargetTriple().isOSAIX()) &&
 Subtarget.hasQuadwordAtomics();
}
```



Comment at: clang/lib/Basic/Targets/PPC.cpp:854
+  HasQuadwordAtomics)
+MaxAtomicInlineWidth = 128;
 }

Can we set `MaxAtomicInlineWidth` in `PPC64TargetInfo::setMaxAtomicWidth()`? 
There is a `TODO` there


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127189

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


[PATCH] D129461: [PowerPC] Support x86 compatible intrinsics on AIX

2022-07-20 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks for the enablement.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129461

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


[PATCH] D129016: [PowerPC] implemented @llvm.ppc.kill.canary to corrupt stack guard

2022-07-19 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Seems current revision is not right. You select the wrong base commit when you 
create the diff?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129016

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


[PATCH] D129461: [PowerPC] Support x86 compatible intrinsics on AIX

2022-07-15 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Driver/ToolChains/AIX.cpp:232
+path::remove_filename(P);
+addSystemInclude(DriverArgs, CC1Args, P);
   }

qiucf wrote:
> shchenz wrote:
> > Can we use `path::parent_path(P)` directly in `addSystemInclude()`? 
> > `remove_filename()` sounds like `ppc_wrappers` is a file.
> It just wraps `parent_path`, and `parent_path` only accepts (and returns) 
> `StringRef`.
```
addSystemInclude(DriverArgs, CC1Args, path::parent_path(P.str()));
```

Above change works for me? I think it should be functionality right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129461

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


[PATCH] D129461: [PowerPC] Support x86 compatible intrinsics on AIX

2022-07-13 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Driver/ToolChains/AIX.cpp:232
+path::remove_filename(P);
+addSystemInclude(DriverArgs, CC1Args, P);
   }

Can we use `path::parent_path(P)` directly in `addSystemInclude()`? 
`remove_filename()` sounds like `ppc_wrappers` is a file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129461

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


[PATCH] D129461: [PowerPC] Support x86 compatible intrinsics on AIX

2022-07-12 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Driver/ToolChains/AIX.cpp:226
+  // Add the PowerPC intrinsic headers (/include/ppc_wrappers)
+  if (!DriverArgs.hasArg(clang::driver::options::OPT_nostdinc) &&
+  !DriverArgs.hasArg(options::OPT_nobuiltininc)) {

`clang::driver::options::OPT_nostdinc` is not same with `options::OPT_nostdinc` 
in line 219?



Comment at: clang/test/CodeGen/PowerPC/ppc-emmintrin.c:631
 // CHECK: %[[ADDR:[0-9a-zA-Z_.]+]] = load double*, double** 
%{{[0-9a-zA-Z_.]+}}, align 8
-// CHECK: %[[VAL:[0-9a-zA-Z_.]+]] = load double, double* %[[ADDR]], align 8
+// CHECK: %[[VAL:[0-9a-zA-Z_.]+]] = load double, double* %[[ADDR]]
 // CHECK: call <2 x double> @vec_splats(double)(double noundef %[[VAL]])

Maybe worth investigating here why loading a double on AIX64 is not aligned to 
8. This should be separated from this patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129461

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


[PATCH] D119407: [PowerPC] [Clang] Add SSE4 and BMI compatible intrinsics implementation for PowerPC

2022-07-10 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Headers/CMakeLists.txt:170
+  ppc_wrappers/immintrin.h
+  ppc_wrappers/tmmintrin.h
+  ppc_wrappers/x86intrin.h

chapuni wrote:
> It doesn't contain , forgot?
@qiucf Looks like an error here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119407

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


[PATCH] D125095: [Clang][AIX] Add .ref in frontend for AIX XCOFF to support `-bcdtors:csect` linker option

2022-07-05 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Sorry, I am really not familiar with these FE stuffs. Need approval from other 
reviewers who know more about this part.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:522
   EmitCXXThreadLocalInitFunc();
+  if (getTriple().isOSAIX()) {
+genAssocMeta();

Seems this dos not follow other functions call's style. Can we call a function 
like `EmitAssociatedMetadata()` here and do the clean up (`cleanupAssoc()` may 
not be needed) in the `EmitAssociatedMetadata()`? 



Comment at: clang/test/CodeGen/PowerPC/aix-init-ref-null.cpp:2
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -emit-llvm -O3 -x c++ \
+// RUN: -debug-info-kind=limited < %s | \
+// RUN:   FileCheck %s

is `-debug-info-kind=limited` or `-O3` necessary in this test? Same as other 
new added cases.



Comment at: clang/test/CodeGen/PowerPC/aix-ref-tls_init.cpp:10
+// CHECK: @r = thread_local global ptr null, align [[ALIGN:[0-9]+]], !dbg 
![[DBG0:[0-9]+]], !associated ![[ASSOC0:[0-9]+]]
+// CHECK: ![[ASSOC0]] = !{ptr @__tls_init}

Not sure if this is right or not. XLC on AIX seems refer to `__tls_get_addr` 
instead  of `__tls_init`...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125095

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


[PATCH] D128652: [PowerPC] Finished kill_canary implementation and debugging

2022-06-30 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Please make sure the patch is able to compile first. I fixed two build 
failures, it still fails : (




Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:221
+  def int_ppc_kill_canary
+  : GCCBuiltin<"__builtin_ppc_kill_canary">, 
+Intrinsic<[],

Need rebase your code. `GCCBuiltin` is not a valid class anymore. See 
https://reviews.llvm.org/D127460



Comment at: llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:5013
 auto IntrinsicID = N->getConstantOperandVal(1);
+
 if (IntrinsicID == Intrinsic::ppc_tdw || IntrinsicID == Intrinsic::ppc_tw) 
{

Nit: avoid this unnecessary change



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:61
 #include "llvm/CodeGen/ValueTypes.h"
+#include "llvm/CodeGen/GlobalISel/IRTranslator.h"
 #include "llvm/IR/CallingConv.h"

Do we need this header? A little strange...



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11148
+EVT VT = DAG.getTargetLoweringInfo().getValueType(DAG.getDataLayout(), 
GV->getType(), true); 
+SDValue canaryLoc = DAG.getGlobalAddress(GV, DL, VT);
+

Please make sure when you post the patch, it is ok to compile. `DL` seems 
undefined, we use `dl` here.

Also please read the coding style of llvm first. 
https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly

`canaryLoc` does not follow the style, should be `CanaryLoc`.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11158
+   canaryLoc,
+   MachinePointerInfo()
+);

All these new added codes need clang-format



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic-aix.ll:5
+
+declare void @llvm.ppc.kill.canary()
+define dso_local void @test_kill_canary() {

We can merge these two files `kill-canary-intrinsic-aix.ll` and 
`kill-canary-intrinsic-linux.ll` into one file with different runlines but with 
different check prefix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128652

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


[PATCH] D125916: [PowerPC] Defined and lowered llvm.ppc.kill.canary intrinsic

2022-06-22 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11136
+MachineFrameInfo  = MF.getFrameInfo();
+int SPI = MFI.getStackProtectorIndex(); // should return  -1
+

Why should return -1?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11144
+
+unsigned int deadBird = 0x4C6C566D; // replaces canary word
+

nit: the first letter should be upper for `deadBird` according to LLVM coding 
style.

And how can we make sure `0x4C6C566D` is not the same with the canary word load 
with `TargetOpcode::LOAD_STACK_GUARD`?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11146
+
+SDValue Store = DAG.getStore( // create store instr, stores (deadBird + 0) 
into addr (frame index + stack protector)
+Op->getOperand(0), 

Need to run clang-format for the new codes.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11160
+return Store;
+break;
+  }

nit: no need for the break after a return



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:3
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu < %s | 
\
+; RUN:   FileCheck %s
+

We may also need to add test cases for AIX 32/64 bit too as stack protector is 
also supported on AIX.



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:13
+; CHECK-NEXT:stw 3, -17(1)
+; CHECK-NEXT:blr
+entry:

This seems wrong. When there is no stack protector related instructions in the 
function, we should not generate the killed store to the stack slot for canary 
word.

The store instruction now will store a word to the caller unexpectedly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125916

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


[PATCH] D125095: [Clang][AIX] Add .ref in frontend for AIX XCOFF to support `-bcdtors:csect` linker option

2022-06-01 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Thanks for doing this. I am not familiar with the frontend, so I may be 
wrong/stupid in the follow comments : )
Hope other experts like @hubert.reinterpretcast can give more meaningful 
comments.

I tested on AIX, seems for static variable `static int x = foo();` in global 
scope, even compile with `-bcdtors:csect`, the init function also will not be 
eliminated. Could you please give an example to show why we need the new 
associated metadata for this case? Thanks.

And we may need to update the docs for `associated` metadata too in 
`docs/LangRef.rst`




Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:542
+  if (getTriple().isOSAIX())
+VFInitTermAssoc.push_back(std::make_pair(D, Fn));
+

Should we use `addVarTermAssoc`?



Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:688
+updateAssociatedFunc(VFInitTermAssoc, LocalCXXGlobalInits, GetElem, 
Fn);
+updateAssociatedFunc(FFDtorTermAssoc, LocalCXXGlobalInits, GetElem, 
Fn);
+  }

`FFDtorTermAssoc` should store the mapping between dtor and term functions? So 
why we need to update this container when we generate wrapper function for init 
function? I think in the init function there should only be ctors related 
functions?

And why we don't need to update for `VarsWithInitTerm`, in that container there 
should be some static variables reply on the wrapper init function?



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:4799
+if (getTriple().isOSAIX())
+  addVarWithInitTerm(D, GV);
+  }

Why do we need to add mapping between a variable and its address? We already 
map the global and its init function in above `EmitCXXGlobalVarDeclInitFunc`?



Comment at: clang/lib/CodeGen/CodeGenModule.h:465
+  /// between dtor and term functions.
+  llvm::SmallVector, 8>
+  VFInitTermAssoc;

Is there any reason why we need `vector` here instead of `map`? Can you give an 
example that shows one global variable will be connected with more than one 
init functions?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125095

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


[PATCH] D124060: [PowerPC] Enable CR bits support for Power8 and above.

2022-04-27 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.cpp:519
 .Default(false);
+  Features["crbits"] = llvm::StringSwitch(CPU)
+.Case("ppc64le", true)

shchenz wrote:
> nemanjai wrote:
> > shchenz wrote:
> > > amyk wrote:
> > > > shchenz wrote:
> > > > > If we set the `+crbits` by the arch name, do we still need the 
> > > > > customization (Turn on crbits for O2 and above) in 
> > > > > `computeFSAdditions()`? 
> > > > Yeah, that's a good point. I looked into this previously, and it 
> > > > appears that addition of `-mcrbits` inside `computeFSAdditions()` may 
> > > > still be necessary. 
> > > > 
> > > > In particular, we have test cases that test pre-POWER8 with 
> > > > optimizations on (or, if no optimization level is provided, then -O2 is 
> > > > assumed the default). In these cases, much of the code changes if the 
> > > > customization inside `computeFSAdditions()` is removed because we would 
> > > > no longer be using crbits pre-P8.
> > > hmm, OK, then we still have the same issue that this patch fixes for 
> > > pre-POWER8. I'm ok with leaving it for now as IMO Power7/Power6 should 
> > > not be major versions for PowerPC.
> > Up until Power8, the only instructions we had that require `crbits` were 
> > CR-logicals (which existed since the POWER architecture - i.e. before 
> > PowerPC). In Power8, we added BCD instructions that also require `crbits`. 
> > So that's why we turn it on for Power8 and up.
> Fail enough.
haha, I mean fair


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124060

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


[PATCH] D124060: [PowerPC] Enable CR bits support for Power8 and above.

2022-04-27 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.cpp:519
 .Default(false);
+  Features["crbits"] = llvm::StringSwitch(CPU)
+.Case("ppc64le", true)

nemanjai wrote:
> shchenz wrote:
> > amyk wrote:
> > > shchenz wrote:
> > > > If we set the `+crbits` by the arch name, do we still need the 
> > > > customization (Turn on crbits for O2 and above) in 
> > > > `computeFSAdditions()`? 
> > > Yeah, that's a good point. I looked into this previously, and it appears 
> > > that addition of `-mcrbits` inside `computeFSAdditions()` may still be 
> > > necessary. 
> > > 
> > > In particular, we have test cases that test pre-POWER8 with optimizations 
> > > on (or, if no optimization level is provided, then -O2 is assumed the 
> > > default). In these cases, much of the code changes if the customization 
> > > inside `computeFSAdditions()` is removed because we would no longer be 
> > > using crbits pre-P8.
> > hmm, OK, then we still have the same issue that this patch fixes for 
> > pre-POWER8. I'm ok with leaving it for now as IMO Power7/Power6 should not 
> > be major versions for PowerPC.
> Up until Power8, the only instructions we had that require `crbits` were 
> CR-logicals (which existed since the POWER architecture - i.e. before 
> PowerPC). In Power8, we added BCD instructions that also require `crbits`. So 
> that's why we turn it on for Power8 and up.
Fail enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124060

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


[PATCH] D124060: [PowerPC] Enable CR bits support for Power8 and above.

2022-04-27 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks for fixing.




Comment at: clang/lib/Basic/Targets/PPC.cpp:519
 .Default(false);
+  Features["crbits"] = llvm::StringSwitch(CPU)
+.Case("ppc64le", true)

amyk wrote:
> shchenz wrote:
> > If we set the `+crbits` by the arch name, do we still need the 
> > customization (Turn on crbits for O2 and above) in `computeFSAdditions()`? 
> Yeah, that's a good point. I looked into this previously, and it appears that 
> addition of `-mcrbits` inside `computeFSAdditions()` may still be necessary. 
> 
> In particular, we have test cases that test pre-POWER8 with optimizations on 
> (or, if no optimization level is provided, then -O2 is assumed the default). 
> In these cases, much of the code changes if the customization inside 
> `computeFSAdditions()` is removed because we would no longer be using crbits 
> pre-P8.
hmm, OK, then we still have the same issue that this patch fixes for 
pre-POWER8. I'm ok with leaving it for now as IMO Power7/Power6 should not be 
major versions for PowerPC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124060

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


[PATCH] D124060: [PowerPC] Enable CR bits support for Power8 and above.

2022-04-26 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

> This patch turns on support for CR bit accesses for Power8 and above. The 
> reason why CR bits are turned on as the default for Power8 and above is that 
> because later architectures make use of builtins and instructions that 
> require CR bit accesses (such as the use of setbc in the vector string 
> isolate predicate and bcd builtins on Power10).

Maybe we also can add some comments in `docs/ClangCommandLineReference.rst` to 
explicitly say that `-mcrbits` will be default to on when PowerPC arch is no 
smaller than 8. I believe some cr-bit operations also exist on Power7 or even 
Power6?




Comment at: clang/lib/Basic/Targets/PPC.cpp:519
 .Default(false);
+  Features["crbits"] = llvm::StringSwitch(CPU)
+.Case("ppc64le", true)

If we set the `+crbits` by the arch name, do we still need the customization 
(Turn on crbits for O2 and above) in `computeFSAdditions()`? 



Comment at: clang/test/Driver/ppc-crbits.cpp:50
+// RUN: %clang -target powerpc64le-unknown-linux-gnu -mcpu=pwr7 -mno-crbits \
+// RUN:   -emit-llvm -S %s -o - | FileCheck %s --check-prefix=HAS-NOCRBITS
+

Do we need some cases for AIX?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124060

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


[PATCH] D123372: [PowerPC] add XLC compat builtin __abs

2022-04-20 Thread ChenZheng via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3c776c70a76e: [PowerPC] add XLC compat builtin __abs 
(authored by shchenz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123372

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c


Index: clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
===
--- clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
+++ clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
@@ -12,6 +12,19 @@
 // Required for size_t. Usually found in stddef.h.
 typedef __SIZE_TYPE__ size_t;
 
+// BOTH-LABEL: @testabs(
+// BOTH-NEXT:  entry:
+// BOTH-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// BOTH-NEXT:store i32 [[A:%.*]], i32* [[A_ADDR]], align 4
+// BOTH-NEXT:[[TMP0:%.*]] = load i32, i32* [[A_ADDR]], align 4
+// BOTH-NEXT:[[NEG:%.*]] = sub nsw i32 0, [[TMP0]]
+// BOTH-NEXT:[[ABSCOND:%.*]] = icmp slt i32 [[TMP0]], 0
+// BOTH-NEXT:[[ABS:%.*]] = select i1 [[ABSCOND]], i32 [[NEG]], i32 [[TMP0]]
+// BOTH-NEXT:ret i32 [[ABS]]
+signed int testabs(signed int a) {
+  return __abs(a);
+}
+
 // 64BIT-LABEL: @testlabs(
 // 64BIT-NEXT:  entry:
 // 64BIT-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -208,6 +208,7 @@
   Builder.defineMacro("__dcbf", "__builtin_dcbf");
   Builder.defineMacro("__fmadd", "__builtin_fma");
   Builder.defineMacro("__fmadds", "__builtin_fmaf");
+  Builder.defineMacro("__abs", "__builtin_abs");
   Builder.defineMacro("__labs", "__builtin_labs");
   Builder.defineMacro("__llabs", "__builtin_llabs");
   Builder.defineMacro("__popcnt4", "__builtin_popcount");


Index: clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
===
--- clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
+++ clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
@@ -12,6 +12,19 @@
 // Required for size_t. Usually found in stddef.h.
 typedef __SIZE_TYPE__ size_t;
 
+// BOTH-LABEL: @testabs(
+// BOTH-NEXT:  entry:
+// BOTH-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// BOTH-NEXT:store i32 [[A:%.*]], i32* [[A_ADDR]], align 4
+// BOTH-NEXT:[[TMP0:%.*]] = load i32, i32* [[A_ADDR]], align 4
+// BOTH-NEXT:[[NEG:%.*]] = sub nsw i32 0, [[TMP0]]
+// BOTH-NEXT:[[ABSCOND:%.*]] = icmp slt i32 [[TMP0]], 0
+// BOTH-NEXT:[[ABS:%.*]] = select i1 [[ABSCOND]], i32 [[NEG]], i32 [[TMP0]]
+// BOTH-NEXT:ret i32 [[ABS]]
+signed int testabs(signed int a) {
+  return __abs(a);
+}
+
 // 64BIT-LABEL: @testlabs(
 // 64BIT-NEXT:  entry:
 // 64BIT-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -208,6 +208,7 @@
   Builder.defineMacro("__dcbf", "__builtin_dcbf");
   Builder.defineMacro("__fmadd", "__builtin_fma");
   Builder.defineMacro("__fmadds", "__builtin_fmaf");
+  Builder.defineMacro("__abs", "__builtin_abs");
   Builder.defineMacro("__labs", "__builtin_labs");
   Builder.defineMacro("__llabs", "__builtin_llabs");
   Builder.defineMacro("__popcnt4", "__builtin_popcount");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123372: [PowerPC] add XLC compat builtin __abs

2022-04-19 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

gentle ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123372

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


[PATCH] D123372: [PowerPC] add XLC compat builtin __abs

2022-04-08 Thread ChenZheng via Phabricator via cfe-commits
shchenz created this revision.
shchenz added reviewers: stefanp, nemanjai, jsji, qiucf, PowerPC.
Herald added a subscriber: kbarton.
Herald added a project: All.
shchenz requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is supplement of D104386 , we add one 
more XLC compat builtin __abs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123372

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c


Index: clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
===
--- clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
+++ clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
@@ -12,6 +12,19 @@
 // Required for size_t. Usually found in stddef.h.
 typedef __SIZE_TYPE__ size_t;
 
+// BOTH-LABEL: @testabs(
+// BOTH-NEXT:  entry:
+// BOTH-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// BOTH-NEXT:store i32 [[A:%.*]], i32* [[A_ADDR]], align 4
+// BOTH-NEXT:[[TMP0:%.*]] = load i32, i32* [[A_ADDR]], align 4
+// BOTH-NEXT:[[NEG:%.*]] = sub nsw i32 0, [[TMP0]]
+// BOTH-NEXT:[[ABSCOND:%.*]] = icmp slt i32 [[TMP0]], 0
+// BOTH-NEXT:[[ABS:%.*]] = select i1 [[ABSCOND]], i32 [[NEG]], i32 [[TMP0]]
+// BOTH-NEXT:ret i32 [[ABS]]
+signed int testabs(signed int a) {
+  return __abs(a);
+}
+
 // 64BIT-LABEL: @testlabs(
 // 64BIT-NEXT:  entry:
 // 64BIT-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -206,6 +206,7 @@
   Builder.defineMacro("__dcbf", "__builtin_dcbf");
   Builder.defineMacro("__fmadd", "__builtin_fma");
   Builder.defineMacro("__fmadds", "__builtin_fmaf");
+  Builder.defineMacro("__abs", "__builtin_abs");
   Builder.defineMacro("__labs", "__builtin_labs");
   Builder.defineMacro("__llabs", "__builtin_llabs");
   Builder.defineMacro("__popcnt4", "__builtin_popcount");


Index: clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
===
--- clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
+++ clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
@@ -12,6 +12,19 @@
 // Required for size_t. Usually found in stddef.h.
 typedef __SIZE_TYPE__ size_t;
 
+// BOTH-LABEL: @testabs(
+// BOTH-NEXT:  entry:
+// BOTH-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// BOTH-NEXT:store i32 [[A:%.*]], i32* [[A_ADDR]], align 4
+// BOTH-NEXT:[[TMP0:%.*]] = load i32, i32* [[A_ADDR]], align 4
+// BOTH-NEXT:[[NEG:%.*]] = sub nsw i32 0, [[TMP0]]
+// BOTH-NEXT:[[ABSCOND:%.*]] = icmp slt i32 [[TMP0]], 0
+// BOTH-NEXT:[[ABS:%.*]] = select i1 [[ABSCOND]], i32 [[NEG]], i32 [[TMP0]]
+// BOTH-NEXT:ret i32 [[ABS]]
+signed int testabs(signed int a) {
+  return __abs(a);
+}
+
 // 64BIT-LABEL: @testlabs(
 // 64BIT-NEXT:  entry:
 // 64BIT-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -206,6 +206,7 @@
   Builder.defineMacro("__dcbf", "__builtin_dcbf");
   Builder.defineMacro("__fmadd", "__builtin_fma");
   Builder.defineMacro("__fmadds", "__builtin_fmaf");
+  Builder.defineMacro("__abs", "__builtin_abs");
   Builder.defineMacro("__labs", "__builtin_labs");
   Builder.defineMacro("__llabs", "__builtin_llabs");
   Builder.defineMacro("__popcnt4", "__builtin_popcount");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D116015: [PowerPC] Add generic fnmsub intrinsic

2022-03-02 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.
This revision is now accepted and ready to land.
Herald added a project: All.

LGTM. Two nits about the comments and tests.

Please wait for some days in case other reviews have some comments.




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15196
const CallExpr *E) {
+  // __builtin_ppc_fnmsub, __builtin_ppc_fnmsubs
   SmallVector Ops;

why add this comment here?



Comment at: clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.c:98
 // CHECK-NEXT:store double [[D:%.*]], double* [[D_ADDR]], align 8
+// CHECK-COUNT-3:load double, double* [[D_ADDR]], align 8
 // CHECK-NEXT:[[TMP0:%.*]] = load double, double* [[D_ADDR]], align 8

If we improve the check lines to CHECK-COUNT, do we still need the original 
CHECKs?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116015

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


[PATCH] D116015: [PowerPC] Add generic fnmsub intrinsic

2022-02-16 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

> hiding the semantics from the optimizer is sometimes a good thing and 
> sometimes a bad thing).

Agree. Imagining a case when the neg and fma (from fnmsub) can both be CSE-ed 
with another neg and fma, so we can totally eliminate the fnmsub. But after we 
convert it to an intrinsic, we may lose the opportunity to CSE the fnmsub.

> Here's a pretty simple case: vector float foo(vector float a, vector float b, 
> vector float c, vector float d) { return __builtin_vsx_xvnmsubasp(c, d, a*b); 
> }
> It current produces xvnegsp+xvmulsp+xvnmaddasp, after this patch it produces 
> xvmulsp+xvnmsubasp. In some complicated cases, we can see much more 
> unexpected instructions generated.

This is narrowed down from a real-world case. After CSE some part of the 
fnmsub, it is hard to optimize it back to a single hardware fnmsub instruction 
as normally we check the use number of a register and if the user number is not 
1, we may exit the combine.

Is it possible to get some perf data for some float workloads with this patch? 
@qiucf




Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1737
+  [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>],
+  [IntrNoMem]>;
   def int_ppc_fre

When `llvm_anyfloat_ty` is `f32` or `f64`, we will generate two intrinsics with 
same semantic. `llvm.ppc.nmsub.f32` + `llvm.ppc.fnmsubs` and 
`llvm.ppc.nmsub.f64` + `llvm.ppc.fnmsub`. At first glance, we seems can not 
delete the `int_ppc_fnmsub` and `int_ppc_fnmsubs`, because they are for XL 
compatibility and XL has seperated fnmsub for float and double and we need to 
map them 1 by 1. Better to check if it is possible to replace `int_ppc_fnmsub` 
and `int_ppc_fnmsubs` with `int_ppc_nmsub`. And if it can be replaced, we can 
use a meaningful name like `int_ppc_fnmsub` for the new intrinsic.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116015

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


[PATCH] D113049: [AIX] Disable tests that fail because of no 64-bit XCOFF object file support

2022-01-06 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks for the explanation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113049

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


[PATCH] D113049: [AIX] Disable tests that fail because of no 64-bit XCOFF object file support

2021-12-22 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Look almost good! Thanks for doing this.




Comment at: clang/test/ASTMerge/codegen-body/test.c:1
+// UNSUPPORTED: powerpc64-ibm-aix
 // RUN: %clang_cc1 -emit-pch -o %t.1.ast %S/Inputs/body1.c

Jake-Egan wrote:
> shchenz wrote:
> > Do we still need this? -emit-obj is already excluded?
> Excluding this test causes regressions because LIT can't find any tests at 
> `/codegen-body` directory:
> ```
> Clang :: utils/update_cc_test_checks/global-hex-value-regex.test
> Clang :: utils/update_cc_test_checks/global-value-regex.test
> ```
> I figure it's easier to mark this test unsupported. 
Is it possible to add `expected-no-diagnostics` for any of the above two RUN 
lines? So we will have a test point and be able to exclude this case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113049

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


[PATCH] D113049: [AIX] Disable tests that fail because of no 64-bit XCOFF object file support

2021-12-21 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/test/ASTMerge/anonymous-fields/test.cpp:1
+// UNSUPPORTED: powerpc64-ibm-aix
 // RUN: %clang_cc1 -emit-pch -o %t.1.ast %S/Inputs/anonymous-fields1.cpp

Do we still need this? `-emit-obj` is already excluded?



Comment at: clang/test/ASTMerge/codegen-body/test.c:1
+// UNSUPPORTED: powerpc64-ibm-aix
 // RUN: %clang_cc1 -emit-pch -o %t.1.ast %S/Inputs/body1.c

Do we still need this? -emit-obj is already excluded?



Comment at: clang/test/ASTMerge/injected-class-name-decl/test.cpp:1
+// UNSUPPORTED: powerpc64-ibm-aix
 // RUN: %clang_cc1 -std=c++1z -emit-pch -o %t.ast %S/Inputs/inject1.cpp

Do we still need this? -emit-obj is already excluded?



Comment at: clang/test/ClangScanDeps/modules-full-by-mod-name.cpp:17
 // RUN:   -mode preprocess-minimized-sources -module-name=header1 >> %t.result
-// RUN: cat %t.result | sed 's:\?:/:g' | FileCheck --check-prefixes=CHECK 
%s
+// RU: cat %t.result | sed 's:\?:/:g' | FileCheck --check-prefixes=CHECK %s
 //

typos?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113049

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


[PATCH] D115503: [DebugInfo][Clang] record the access flag for class/struct/union types.

2021-12-17 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

In D115503#3199459 , @Esme wrote:

> In D115503#3195171 , @dblaikie 
> wrote:
>
>> Ah, cool - could you include % growth on those rows
>
> Thanks, I edited the table in the previous comment.
>
>> (hmm, .debug_line and .debug_str shouldn't be changing in size with this 
>> change, right? If you use the same clang version to test the two cases (if 
>> you're using a bootstrap with/without the patch applied, then the patch 
>> changes itself would show up as changes here))
>
> Hmm...it's a little strange. I got these data by:
>
> 1. pull a base llvm-project branch --> source codes
> 2. build the source --> clang1
> 3. build the codes after applying the patch  --> clang2
> 4. use clang1 to build the source (no patch) --> clang-before
> 5. use clang2 to build the source (no patch) --> clang-after
> 6. compare the size between clang-before and clang-after
>
> I reproduced these steps on another base branch, and saw similar changes 
> (i.e. .debug_line and .debug_str changed in size)...
> But I think the change is so small as to be negligible?
>
>> & if you could include this table in the commit message, that'd be great!
>>
>> (can you commit this yourself, or do you need someone to do that for you?)
>
> I will include this table when committing, thanks!

`.debug_str` will be changed because of `DW_AT_producer`? We are using 
different compilers to compile the source.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115503

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


[PATCH] D113049: [AIX] Disable tests that fail because of no 64-bit XCOFF object file support

2021-12-15 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/test/ClangScanDeps/modules-full-by-mod-name.cpp:1
+// UNSUPPORTED: powerpc64-ibm-aix
 // RUN: rm -rf %t.dir

Jake-Egan wrote:
> jsji wrote:
> > there is no `fmodule-format=obj` here, why are we failing here?
> > 
> They have the same error as the other tests:
> 
> ```
> 64-bit XCOFF object files are not supported yet.
> ```
Which RUN line causes the `64-bit XCOFF object files are not supported yet` 
assertion? NO `-emit-obj` or `fmodule-format=obj` found in all the RUN lines.



Comment at: clang/test/lit.cfg.py:253
+   # 64-bit object files are not supported on AIX, so exclude the 
tests.
+   if ('-emit-obj' in data or '-fmodule-format=obj' in data) and '64' 
in config.target_triple:
+   config.excludes += [ filename ]

Can we add `-fintegrated-as` here too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113049

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


[PATCH] D115503: [DebugInfo][Clang] record the access flag for class/struct/union types.

2021-12-12 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision as: shchenz.
shchenz added a comment.
This revision is now accepted and ready to land.

Thanks for fixing this. LGTM. Please wait for @dblaikie comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115503

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


[PATCH] D115503: [DebugInfo][Clang] record the access flag for class/struct/union types.

2021-12-12 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/test/CodeGenCXX/debug-info-access.cpp:28
 
+class C {
+public:

Esme wrote:
> dblaikie wrote:
> > shchenz wrote:
> > > Will we generate a redundant flag if we define a private type in the 
> > > class or a public type in the struct/union? Maybe we could add a case for 
> > > that too.
> > How',s this compare to member variables? Do we always put the access level 
> > on members even when it's the default? Perhaps the Flag handling code could 
> > be generalized and used between both these cases & if one of them gets 
> > fixed in favor of not explicitly specifying the default, both would benefit.
> Member variables use the same Flag handling code, i.e. getAccessFlag(), which 
> returns 0 if the access specifier equals the default for the containing type.
> Therefore for both cases we will not record the access flag when it's the 
> default.
> The case where the default access is not explicitly specified is added now.
Good to know `getAccessFlag()` already takes care of this case. Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115503

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


[PATCH] D115503: [DebugInfo][Clang] record the access flag for class/struct/union types.

2021-12-12 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/test/CodeGenCXX/debug-info-access.cpp:28
 
+class C {
+public:

Will we generate a redundant flag if we define a private type in the class or a 
public type in the struct/union? Maybe we could add a case for that too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115503

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


[PATCH] D113049: [AIX] Disable tests that fail because of no 64-bit XCOFF object file support

2021-11-03 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

This seems not right. Now we disable too many debug cases for object mode even 
for 32bit target. Maybe we should test clang (built with 
`--default-target-triple=powerpc64-ibm-aix`)  after our backend support 64-bit 
object mode(`-filetype=obj`)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113049

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


[PATCH] D111336: [AIX] Disable tests failing due to missing DWARF sections

2021-10-07 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111336

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


[PATCH] D111169: [AIX] Disable tests failing due to assert on DWARF object writing

2021-10-07 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

In D69#3048311 , @Jake-Egan wrote:

> In D69#3047761 , @shchenz wrote:
>
>> Thanks for working on this.
>>
>> Could you please help to rerun the affected cases after applying D97184 
>> ? That patch is approved and I will deliver 
>> it soon.
>
> I reran the tests with the patch. All the tests pass.

Thanks, D97184  is committed as 
https://reviews.llvm.org/rG5f4c91583ee772a6ce2c4f192e25b07e6075eb00
This patch should not be needed now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69

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


[PATCH] D111169: [AIX] Disable tests failing due to assert on DWARF object writing

2021-10-07 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Thanks for working on this.

Could you please help to rerun the affected cases after applying D97184 
? That patch is approved and I will deliver it 
soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69

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


[PATCH] D105512: [AIX] Don't pass no-integrated-as by default

2021-07-07 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105512

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


[PATCH] D105512: [AIX] Don't pass no-integrated-as by default

2021-07-07 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

I think it is ok to not passing `-no-integrated-as` to cc1 as the default value 
for backend for XCOFF is no integrated assembler. Can we make the logic be 
simpler here?




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5043
+  // option to disable integrated-as explictly.
+  if (!TC.useIntegratedAs() && !TC.parseInlineAsmUsingAsmParser())
 CmdArgs.push_back("-no-integrated-as");

Do we need a new virtual function `parseInlineAsmUsingAsmParser()` in the tool 
chain file? Maybe we can use `isOSAIX()` and `Args.hasFlag(` here to change the 
behaviour for AIX. inline assembly parser sounds like not a toolchain level 
flag?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105512

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


[PATCH] D104118: [OpenCL] Use DW_LANG_OpenCL language tag for OpenCL C

2021-06-23 Thread ChenZheng via Phabricator via cfe-commits
shchenz accepted this revision.
shchenz added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104118

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


[PATCH] D104291: [Debug-Info] strict dwarf for DW_LANG_C_plus_plus_14

2021-06-17 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

In D104291#2821581 , @stuart wrote:

>> There is no `CPlusPlus03` in `LangOptions`, so it is better not to merge 
>> `DW_LANG_C_plus_plus_03` support with D99250 
>> .
>
> Oh - I see, `c++03` is defined in LangStandards.def an alias for `c++98`, as 
> the former essentially consists of bugfixes for the latter. This loosely 
> suggests to me that C++03 implementations are (likely to be / mostly?) 
> conformant to C++98, but that C++98 implementations may not be fully 
> conformant to C++03. Given this alias, it doesn't seem at all clear to me 
> which of DW_LANG_C_plus_plus_98 and DW_LANG_C_plus_plus_03 would be the 
> better choice, if both C++98 and C++03 must share a language tag... but I 
> presume this has been discussed before. (It also doesn't seem clear whether 
> it would be better to model "c++98" as an alias for "c++03".)
>
>> Yes, we don't have `DW_LANG_C_plus_plus_17` and `DW_LANG_C_plus_plus_20` in 
>> clang for now. I guess this is because clang does not support DWARF 6. DWARF 
>> 6 is not officially released? Once DWARF 6 is released and clang starts to 
>> support DWARF 6, I think we should add the support for 
>> `DW_LANG_C_plus_plus_17` and `DW_LANG_C_plus_plus_20` in the place that this 
>> patch changes.
>
> New DWARF language codes  are published 
> ahead of the release of the next version of DWARF, so that they may be used 
> by implementations without having to wait for new DWARF version.
>
> It would therefore make sense to go ahead and add `DW_LANG_C_plus_plus_17` 
> and `DW_LANG_C_plus_plus_20` now, without waiting, but only in the non-strict 
> DWARF mode. (There would be the question of whether it would still make sense 
> in the code to say "DwarfVersion >= 6" given that DWARF 6 would be otherwise 
> unsupported... but I don't have a strong view on that question.)

I think it would be strange to check `DwarfVersion >= 6` if we can not set 
dwarf version to 6 by anyways. Maybe we can first add the DWARF 6 support to 
the front end first. This is the patch where `-gdwarf-5` was introduced 
https://reviews.llvm.org/rG3cb592d6b60c. Seems it was also before DWARF 5 was 
official released.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104291

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


[PATCH] D104291: [Debug-Info] strict dwarf for DW_LANG_C_plus_plus_14

2021-06-16 Thread ChenZheng via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4590b406c02e: [Debug-Info] guard DW_LANG_C_plus_plus_14 
under strict dwarf (authored by shchenz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104291

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-programming-language.cpp


Index: clang/test/CodeGenCXX/debug-info-programming-language.cpp
===
--- clang/test/CodeGenCXX/debug-info-programming-language.cpp
+++ clang/test/CodeGenCXX/debug-info-programming-language.cpp
@@ -1,13 +1,18 @@
-// RUN: %clang_cc1 -dwarf-version=5  -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
-// RUN: | FileCheck --check-prefix=CHECK-DWARF5 %s
-// RUN: %clang_cc1 -dwarf-version=3  -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
-// RUN: | FileCheck --check-prefix=CHECK-DWARF3 %s
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -gstrict-dwarf -emit-llvm -triple 
%itanium_abi_triple %s -o - \
+// RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited 
| FileCheck %s
+// RUN: %clang_cc1 -dwarf-version=5 -gstrict-dwarf -emit-llvm -triple 
%itanium_abi_triple %s -o - \
+// RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
 
 int main() {
   return 0;
 }
 
-// CHECK-DWARF5: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
-// CHECK-DWARF3: distinct !DICompileUnit(language: DW_LANG_C_plus_plus,
+// CHECK-CPP14: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
+// CHECK: distinct !DICompileUnit(language: DW_LANG_C_plus_plus,
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -568,9 +568,11 @@
   if (LO.CPlusPlus) {
 if (LO.ObjC)
   LangTag = llvm::dwarf::DW_LANG_ObjC_plus_plus;
-else if (LO.CPlusPlus14 && CGM.getCodeGenOpts().DwarfVersion >= 5)
+else if (LO.CPlusPlus14 && (!CGM.getCodeGenOpts().DebugStrictDwarf ||
+CGM.getCodeGenOpts().DwarfVersion >= 5))
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus_14;
-else if (LO.CPlusPlus11 && CGM.getCodeGenOpts().DwarfVersion >= 5)
+else if (LO.CPlusPlus11 && (!CGM.getCodeGenOpts().DebugStrictDwarf ||
+CGM.getCodeGenOpts().DwarfVersion >= 5))
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus_11;
 else
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus;


Index: clang/test/CodeGenCXX/debug-info-programming-language.cpp
===
--- clang/test/CodeGenCXX/debug-info-programming-language.cpp
+++ clang/test/CodeGenCXX/debug-info-programming-language.cpp
@@ -1,13 +1,18 @@
-// RUN: %clang_cc1 -dwarf-version=5  -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s -o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
-// RUN: | FileCheck --check-prefix=CHECK-DWARF5 %s
-// RUN: %clang_cc1 -dwarf-version=3  -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s -o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
-// RUN: | FileCheck --check-prefix=CHECK-DWARF3 %s
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -gstrict-dwarf -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited | FileCheck %s
+// RUN: %clang_cc1 -dwarf-version=5 -gstrict-dwarf -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
 
 int main() {
   return 0;
 }
 
-// CHECK-DWARF5: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
-// CHECK-DWARF3: distinct !DICompileUnit(language: DW_LANG_C_plus_plus,
+// CHECK-CPP14: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
+// CHECK: distinct !DICompileUnit(language: DW_LANG_C_plus_plus,
Index: clang/lib/CodeGen/CGDebugInfo.cpp

[PATCH] D104291: [Debug-Info] strict dwarf for DW_LANG_C_plus_plus_14

2021-06-16 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Thanks for review @stuart

In D104291#2819398 , @stuart wrote:

> This looks good to me.
>
> @jzzheng22 informs me there was a comment in D99250 
>  to the effect that DW_LANG_C_plus_plus_03 
> is not emitted, at all - it too was introduced in DWARF 5.  I wonder if this 
> should be addressed in a separate commit?

Yes, this was noticed when D99250  was posted. 
There is no `CPlusPlus03` in `LangOptions`, so it is better not to merge 
`DW_LANG_C_plus_plus_03` support with D99250 .

> As mentioned in D104118 , there are 
> language codes of DW_LANG_C_plus_plus_17 and DW_LANG_C_plus_plus_20 that will 
> be introduced in DWARF 6, which it would be good to use in non-strict mode.  
> This would allow us to emit the more proper code of DW_LANG_C_plus_plus_17 
> (instead of DW_LANG_C_plus_plus_14) for //C++ for OpenCL//, while we wait for 
> DW_LANG_CPP_for_OpenCL to get added, as requested at 
> http://dwarfstd.org/ShowIssue.php?issue=210514.1.  Should this be addressed 
> in a third commit?

Yes, we don't have `DW_LANG_C_plus_plus_17` and `DW_LANG_C_plus_plus_20` in 
clang for now. I guess this is because clang does not support DWRAF 6. DWARF 6 
is not officially released? Once DWARF 6 is released and clang starts to 
support DWARF 6, I think we should add the support for `DW_LANG_C_plus_plus_17` 
and `DW_LANG_C_plus_plus_20` in the place that this patch changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104291

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


[PATCH] D104291: [Debug-Info] strict dwarf for DW_LANG_C_plus_plus_14

2021-06-15 Thread ChenZheng via Phabricator via cfe-commits
shchenz created this revision.
shchenz added reviewers: dblaikie, aprantl, Esme, stuart, PowerPC.
shchenz added a project: debug-info.
shchenz requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This partially reverts the change in https://reviews.llvm.org/D99250.
Now we also generate `DW_LANG_C_plus_plus_14` or `DW_LANG_C_plus_plus_11` for 
non-strict mode.

We can provide more accurate language info for consumers which does not require 
strict DWARF.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104291

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-programming-language.cpp


Index: clang/test/CodeGenCXX/debug-info-programming-language.cpp
===
--- clang/test/CodeGenCXX/debug-info-programming-language.cpp
+++ clang/test/CodeGenCXX/debug-info-programming-language.cpp
@@ -1,13 +1,18 @@
-// RUN: %clang_cc1 -dwarf-version=5  -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
-// RUN: | FileCheck --check-prefix=CHECK-DWARF5 %s
-// RUN: %clang_cc1 -dwarf-version=3  -emit-llvm -triple %itanium_abi_triple %s 
-o - \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s 
-o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
-// RUN: | FileCheck --check-prefix=CHECK-DWARF3 %s
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -gstrict-dwarf -emit-llvm -triple 
%itanium_abi_triple %s -o - \
+// RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited 
| FileCheck %s
+// RUN: %clang_cc1 -dwarf-version=5 -gstrict-dwarf -emit-llvm -triple 
%itanium_abi_triple %s -o - \
+// RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
 
 int main() {
   return 0;
 }
 
-// CHECK-DWARF5: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
-// CHECK-DWARF3: distinct !DICompileUnit(language: DW_LANG_C_plus_plus,
+// CHECK-CPP14: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
+// CHECK: distinct !DICompileUnit(language: DW_LANG_C_plus_plus,
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -568,9 +568,11 @@
   if (LO.CPlusPlus) {
 if (LO.ObjC)
   LangTag = llvm::dwarf::DW_LANG_ObjC_plus_plus;
-else if (LO.CPlusPlus14 && CGM.getCodeGenOpts().DwarfVersion >= 5)
+else if (LO.CPlusPlus14 && (!CGM.getCodeGenOpts().DebugStrictDwarf ||
+CGM.getCodeGenOpts().DwarfVersion >= 5))
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus_14;
-else if (LO.CPlusPlus11 && CGM.getCodeGenOpts().DwarfVersion >= 5)
+else if (LO.CPlusPlus11 && (!CGM.getCodeGenOpts().DebugStrictDwarf ||
+CGM.getCodeGenOpts().DwarfVersion >= 5))
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus_11;
 else
   LangTag = llvm::dwarf::DW_LANG_C_plus_plus;


Index: clang/test/CodeGenCXX/debug-info-programming-language.cpp
===
--- clang/test/CodeGenCXX/debug-info-programming-language.cpp
+++ clang/test/CodeGenCXX/debug-info-programming-language.cpp
@@ -1,13 +1,18 @@
-// RUN: %clang_cc1 -dwarf-version=5  -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN: %clang_cc1 -dwarf-version=5 -emit-llvm -triple %itanium_abi_triple %s -o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
-// RUN: | FileCheck --check-prefix=CHECK-DWARF5 %s
-// RUN: %clang_cc1 -dwarf-version=3  -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -emit-llvm -triple %itanium_abi_triple %s -o - \
 // RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
-// RUN: | FileCheck --check-prefix=CHECK-DWARF3 %s
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
+// RUN: %clang_cc1 -dwarf-version=3 -gstrict-dwarf -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited | FileCheck %s
+// RUN: %clang_cc1 -dwarf-version=5 -gstrict-dwarf -emit-llvm -triple %itanium_abi_triple %s -o - \
+// RUN:   -x c++ -std=c++14 -O0 -disable-llvm-passes -debug-info-kind=limited \
+// RUN:   | FileCheck --check-prefix=CHECK-CPP14 %s
 
 int main() {
   return 0;
 }
 
-// CHECK-DWARF5: distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14,
-// CHECK-DWARF3: distinct !DICompileUnit(language: DW_LANG_C_plus_plus,
+// CHECK-CPP14: distinct 

[PATCH] D104118: [OpenCL] Use DW_LANG_OpenCL language tag for OpenCL C

2021-06-15 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:579
 LangTag = llvm::dwarf::DW_LANG_ObjC;
+  } else if (LO.OpenCL && CGM.getCodeGenOpts().DwarfVersion >= 5) {
+LangTag = llvm::dwarf::DW_LANG_OpenCL;

stuart wrote:
> shchenz wrote:
> > I think for non-strict DWARF mode, we still can generate `DW_LANG_OpenCL` 
> > for the DWARF version lower than 5? Seems we also need to fix above 
> > `DW_LANG_C_plus_plus_14` and `DW_LANG_C_plus_plus_11`
> If we have a `-gstrict-dwarf` option for this, then it would seem better to 
> add `DW_LANG_C_plus_plus_17` and `DW_LANG_C_plus_plus_20` definitions and 
> generate those for the `!CGM.getCodeGenOpts().DebugStrictDwarf` case. //C++ 
> for OpenCL// would then use one of the more recent language tag values for 
> the time being (without any special logic).
I added a patch https://reviews.llvm.org/D104291 for `DW_LANG_C_plus_plus_14` 
and `DW_LANG_C_plus_plus_11`.
I think `DW_LANG_OpenCL` should be in the same situation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104118

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


[PATCH] D104118: [OpenCL] Use DW_LANG_OpenCL language tag for OpenCL C

2021-06-14 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:579
 LangTag = llvm::dwarf::DW_LANG_ObjC;
+  } else if (LO.OpenCL && CGM.getCodeGenOpts().DwarfVersion >= 5) {
+LangTag = llvm::dwarf::DW_LANG_OpenCL;

I think for non-strict DWARF mode, we still can generate `DW_LANG_OpenCL` for 
the DWARF version lower than 5? Seems we also need to fix above 
`DW_LANG_C_plus_plus_14` and `DW_LANG_C_plus_plus_11`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104118

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-24 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Thanks for your review! @dblaikie @aprantl


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-24 Thread ChenZheng via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG99d45ed22fd9: [Debug-Info] handle 
DW_TAG_rvalue_reference_type at strict DWARF. (authored by shchenz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp


Index: clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
===
--- clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
+++ clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
@@ -1,4 +1,8 @@
 // RUN: %clang_cc1 -std=c++11 -emit-llvm -debug-info-kind=limited -triple 
x86_64-apple-darwin %s -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -dwarf-version=4 -gstrict-dwarf -emit-llvm 
-debug-info-kind=limited \
+// RUN:   -triple x86_64-apple-darwin %s -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -dwarf-version=3 -gstrict-dwarf -emit-llvm 
-debug-info-kind=limited \
+// RUN:  -triple x86_64-apple-darwin %s -o - | FileCheck %s 
--check-prefix=NORVALUE
 
 extern "C" {
 extern int printf(const char * format, ...);
@@ -10,3 +14,4 @@
 
 // CHECK: !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: 
![[INT:[0-9]+]], size: 64)
 // CHECK: ![[INT]] = !DIBasicType(name: "int"
+// NORVALUE: !DIDerivedType(tag: DW_TAG_reference_type, baseType: 
![[INT:[0-9]+]], size: 64)
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2989,8 +2989,13 @@
 
 llvm::DIType *CGDebugInfo::CreateType(const RValueReferenceType *Ty,
   llvm::DIFile *Unit) {
-  return CreatePointerLikeType(llvm::dwarf::DW_TAG_rvalue_reference_type, Ty,
-   Ty->getPointeeType(), Unit);
+  llvm::dwarf::Tag Tag = llvm::dwarf::DW_TAG_rvalue_reference_type;
+  // DW_TAG_rvalue_reference_type was introduced in DWARF 4.
+  if (CGM.getCodeGenOpts().DebugStrictDwarf &&
+  CGM.getCodeGenOpts().DwarfVersion < 4)
+Tag = llvm::dwarf::DW_TAG_reference_type;
+
+  return CreatePointerLikeType(Tag, Ty, Ty->getPointeeType(), Unit);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const MemberPointerType *Ty,


Index: clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
===
--- clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
+++ clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
@@ -1,4 +1,8 @@
 // RUN: %clang_cc1 -std=c++11 -emit-llvm -debug-info-kind=limited -triple x86_64-apple-darwin %s -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -dwarf-version=4 -gstrict-dwarf -emit-llvm -debug-info-kind=limited \
+// RUN:   -triple x86_64-apple-darwin %s -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -dwarf-version=3 -gstrict-dwarf -emit-llvm -debug-info-kind=limited \
+// RUN:  -triple x86_64-apple-darwin %s -o - | FileCheck %s --check-prefix=NORVALUE
 
 extern "C" {
 extern int printf(const char * format, ...);
@@ -10,3 +14,4 @@
 
 // CHECK: !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: ![[INT:[0-9]+]], size: 64)
 // CHECK: ![[INT]] = !DIBasicType(name: "int"
+// NORVALUE: !DIDerivedType(tag: DW_TAG_reference_type, baseType: ![[INT:[0-9]+]], size: 64)
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2989,8 +2989,13 @@
 
 llvm::DIType *CGDebugInfo::CreateType(const RValueReferenceType *Ty,
   llvm::DIFile *Unit) {
-  return CreatePointerLikeType(llvm::dwarf::DW_TAG_rvalue_reference_type, Ty,
-   Ty->getPointeeType(), Unit);
+  llvm::dwarf::Tag Tag = llvm::dwarf::DW_TAG_rvalue_reference_type;
+  // DW_TAG_rvalue_reference_type was introduced in DWARF 4.
+  if (CGM.getCodeGenOpts().DebugStrictDwarf &&
+  CGM.getCodeGenOpts().DwarfVersion < 4)
+Tag = llvm::dwarf::DW_TAG_reference_type;
+
+  return CreatePointerLikeType(Tag, Ty, Ty->getPointeeType(), Unit);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const MemberPointerType *Ty,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-21 Thread ChenZheng via Phabricator via cfe-commits
shchenz requested review of this revision.
shchenz added a comment.

OK, thanks David @dblaikie .

Ping for your comments, we need some discussion here to decide we should fix 
this in FE or BE. See more in https://reviews.llvm.org/D100630#2762354

@aprantl @probinson and other reviewers ^- ^


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-20 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

@dblaikie Hi David, should we change to use the FE solution? Maybe we should 
fix the issue where it happens? We should not let the FE generate the un-strict 
dwarf tag in FE and then fix it in the BE. I have changed this patch to fix 
this strict DWARF issue in FE. What do you think? Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-20 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 346680.
shchenz added a comment.

1: use the solution in the FE


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp


Index: clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
===
--- clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
+++ clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
@@ -1,4 +1,8 @@
 // RUN: %clang_cc1 -std=c++11 -emit-llvm -debug-info-kind=limited -triple 
x86_64-apple-darwin %s -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -dwarf-version=4 -gstrict-dwarf -emit-llvm 
-debug-info-kind=limited \
+// RUN:   -triple x86_64-apple-darwin %s -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -dwarf-version=3 -gstrict-dwarf -emit-llvm 
-debug-info-kind=limited \
+// RUN:  -triple x86_64-apple-darwin %s -o - | FileCheck %s 
--check-prefix=NORVALUE
 
 extern "C" {
 extern int printf(const char * format, ...);
@@ -10,3 +14,4 @@
 
 // CHECK: !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: 
![[INT:[0-9]+]], size: 64)
 // CHECK: ![[INT]] = !DIBasicType(name: "int"
+// NORVALUE: !DIDerivedType(tag: DW_TAG_reference_type, baseType: 
![[INT:[0-9]+]], size: 64)
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2989,8 +2989,13 @@
 
 llvm::DIType *CGDebugInfo::CreateType(const RValueReferenceType *Ty,
   llvm::DIFile *Unit) {
-  return CreatePointerLikeType(llvm::dwarf::DW_TAG_rvalue_reference_type, Ty,
-   Ty->getPointeeType(), Unit);
+  llvm::dwarf::Tag Tag = llvm::dwarf::DW_TAG_rvalue_reference_type;
+  // DW_TAG_rvalue_reference_type was introduced in DWARF 4.
+  if (CGM.getCodeGenOpts().DebugStrictDwarf &&
+  CGM.getCodeGenOpts().DwarfVersion < 4)
+Tag = llvm::dwarf::DW_TAG_reference_type;
+
+  return CreatePointerLikeType(Tag, Ty, Ty->getPointeeType(), Unit);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const MemberPointerType *Ty,


Index: clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
===
--- clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
+++ clang/test/CodeGenCXX/debug-info-rvalue-ref.cpp
@@ -1,4 +1,8 @@
 // RUN: %clang_cc1 -std=c++11 -emit-llvm -debug-info-kind=limited -triple x86_64-apple-darwin %s -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -dwarf-version=4 -gstrict-dwarf -emit-llvm -debug-info-kind=limited \
+// RUN:   -triple x86_64-apple-darwin %s -o - | FileCheck %s
+// RUN: %clang_cc1 -std=c++11 -dwarf-version=3 -gstrict-dwarf -emit-llvm -debug-info-kind=limited \
+// RUN:  -triple x86_64-apple-darwin %s -o - | FileCheck %s --check-prefix=NORVALUE
 
 extern "C" {
 extern int printf(const char * format, ...);
@@ -10,3 +14,4 @@
 
 // CHECK: !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: ![[INT:[0-9]+]], size: 64)
 // CHECK: ![[INT]] = !DIBasicType(name: "int"
+// NORVALUE: !DIDerivedType(tag: DW_TAG_reference_type, baseType: ![[INT:[0-9]+]], size: 64)
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2989,8 +2989,13 @@
 
 llvm::DIType *CGDebugInfo::CreateType(const RValueReferenceType *Ty,
   llvm::DIFile *Unit) {
-  return CreatePointerLikeType(llvm::dwarf::DW_TAG_rvalue_reference_type, Ty,
-   Ty->getPointeeType(), Unit);
+  llvm::dwarf::Tag Tag = llvm::dwarf::DW_TAG_rvalue_reference_type;
+  // DW_TAG_rvalue_reference_type was introduced in DWARF 4.
+  if (CGM.getCodeGenOpts().DebugStrictDwarf &&
+  CGM.getCodeGenOpts().DwarfVersion < 4)
+Tag = llvm::dwarf::DW_TAG_reference_type;
+
+  return CreatePointerLikeType(Tag, Ty, Ty->getPointeeType(), Unit);
 }
 
 llvm::DIType *CGDebugInfo::CreateType(const MemberPointerType *Ty,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-17 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

In D100630#2760972 , @dblaikie wrote:

> This isn't the sort of thing I'd like to leave to a FIXME later - seems like 
> the sort of thing we shouldn't create now to fix later.
>
> @aprantl mind having a second look at this to consider the situation further?

OK. Let me summary the two solutions here:
1: fixed in the FE. See patch 
https://reviews.llvm.org/D100630?vs=on=338035#toc.
Advantage:

- the DWARF info for `DW_TAG_rvalue_reference_type` and `DW_TAG_reference_type` 
is cached, so we will not have redundant info;
- FE also respects strict dwarf option;

Disadvantage:

- No common interface for strict dwarf option.

2: fixed in the BE. See current patch.
Advantage:

- there is a common interface for tags adding, so we can add strict dwarf 
support in one place

Disadvantage:

- Redundant DWARF info since the final DWARF info adding in BE has no cache 
mechanism. And maybe there should be no such mechanism because after we add a 
DIE tag, we may add an attribute anywhere later, so it is hard to tell the DIE 
tag is identical when we create the DIE tag. If we optimize the redundant DWARF 
tag in the place where we add the fix, what about when we need to add another 
attribute to one of the identical DIE tags? Splitting them again into two 
different DIE tags?
- IR Metadata does not respect the strict DWARF option.

Welcome your comments? @dblaikie @aprantl @probinson and other reviewers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-14 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

Thanks for your comments! @dblaikie @aprantl . I think we have an agreement 
that we should handle the strict dwarf tag in the backend.

And for duplicated tags issue, since it may need a while to fix, I have added a 
TODO in the code change and also update to test case to show the duplicated 
tags issue and also a FIXME in the case.

Do you think it is good to treat it as a FIXME for now? I currently have no 
time to fix this, but I will keep this in mind and will fix this later when I 
get a better understanding of the DWARF codes. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-14 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 345333.
shchenz added a comment.

1: add the FIXME for the duplicated tags issue


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

Files:
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,67 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as 
DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; CHECK-NEXT: DW_AT_type {{.*}} "int"
+; CHECK: DW_TAG_base_type
+; CHECK-NOT: DW_TAG
+; CHECK: DW_AT_name {{.*}}"int"
+; CHECK: DW_TAG_reference_type
+; CHECK-NEXT: DW_AT_type {{.*}} "int"
+;
+; FIXME: remove the redundant tag DW_TAG_reference_type. We only need one tag
+; DW_TAG_reference_type with base type int.
+;
+; STRICT-NOT: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+; STRICT-NEXT: DW_AT_type {{.*}} "int"
+; STRICT: DW_TAG_base_type
+; STRICT-NOT: DW_TAG
+; STRICT: DW_AT_name {{.}}"int"
+; STRICT: DW_TAG_reference_type
+; STRICT-NEXT: DW_AT_type {{.*}} "int"
+
+define void @_Z2f1OiRi(i32* dereferenceable(4) %0, i32* dereferenceable(4) %1) 
#0 !dbg !9 {
+  %3 = alloca i32*, align 8
+  %4 = alloca i32*, align 8
+  store i32* %0, i32** %3, align 8
+  call void @llvm.dbg.declare(metadata i32** %3, metadata !15, metadata 
!DIExpression()), !dbg !16
+  store i32* %1, i32** %4, align 8
+  call void @llvm.dbg.declare(metadata i32** %4, metadata !17, metadata 
!DIExpression()), !dbg !18
+  ret void, !dbg !19
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6, !7}
+!llvm.ident = !{!8}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, 
producer: "clang version 13.0.0", isOptimized: false, runtimeVersion: 0, 
emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: 
None)
+!1 = !DIFile(filename: "1.cpp", directory: "./")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 3}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{i32 7, !"uwtable", i32 1}
+!7 = !{i32 7, !"frame-pointer", i32 2}
+!8 = !{!"clang version 13.0.0"}
+!9 = distinct !DISubprogram(name: "f1", linkageName: "_Z2f1OiRi", scope: !1, 
file: !1, line: 1, type: !10, scopeLine: 1, flags: DIFlagPrototyped, spFlags: 
DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!10 = !DISubroutineType(types: !11)
+!11 = !{null, !12, !14}
+!12 = !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: !13, size: 
64)
+!13 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!14 = !DIDerivedType(tag: DW_TAG_reference_type, baseType: !13, size: 64)
+!15 = !DILocalVariable(name: "x", arg: 1, scope: !9, file: !1, line: 1, type: 
!12)
+!16 = !DILocation(line: 1, column: 15, scope: !9)
+!17 = !DILocalVariable(name: "y", arg: 2, scope: !9, file: !1, line: 1, type: 
!14)
+!18 = !DILocation(line: 1, column: 23, scope: !9)
+!19 = !DILocation(line: 2, column: 1, scope: !9)
Index: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -386,6 +386,22 @@
 }
 
 DIE ::createAndAddDIE(dwarf::Tag Tag, DIE , const DINode *N) {
+  // For strict DWARF mode, only generate tags available to current DWARF
+  // version.
+  if (Asm->TM.Options.DebugStrictDwarf &&
+  DD->getDwarfVersion() < dwarf::TagVersion(Tag)) {
+// See if there is any replacement for some tags.
+// TODO: the naively replacement may introduce duplicated tags. For 
example,
+// before the replacement, we have DW_TAG_rvalue_reference_type with type
+// int and DW_TAG_reference_type with type int, after the replacement, now
+// we have two DW_TAG_reference_type with type int. We should fix this.
+if (Tag == dwarf::DW_TAG_rvalue_reference_type &&
+DD->getDwarfVersion() >= 3)
+  Tag = dwarf::DW_TAG_reference_type;
+else
+  // Assertion for other cases.
+  assert(false && "Tag is generated not following strict DWARF!");
+  }
   DIE  = Parent.addChild(DIE::get(DIEValueAllocator, Tag));
   if (N)
 insertDIE(N, );


Index: 

[PATCH] D100826: [Debug-Info][NFC] add -gstrict-dwarf support in backend

2021-05-13 Thread ChenZheng via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa0ca4c46ca35: [Debug-Info] add -gstrict-dwarf support in 
backend (authored by shchenz).

Changed prior to commit:
  https://reviews.llvm.org/D100826?vs=339840=345022#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100826

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/test/DebugInfo/PowerPC/strict-dwarf.ll

Index: llvm/test/DebugInfo/PowerPC/strict-dwarf.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf.ll
@@ -0,0 +1,60 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s
+
+; FIXME: when -strict-dwarf=true is specified, we should check "STRICT" to tell
+; that with DWARF 4, we should not generate DWARF 5 attribute DW_AT_noreturn and
+; DW_AT_alignment.
+
+; CHECK: DW_AT_alignment
+; CHECK: DW_AT_noreturn
+; STRICT-NOT: DW_AT_noreturn
+; STRICT-NOT: DW_AT_alignment
+
+@_ZL3var = internal global i32 0, align 16, !dbg !0
+
+; Function Attrs: noinline noreturn optnone uwtable mustprogress
+define dso_local void @_Z1fv() #0 !dbg !12 {
+entry:
+  call void @_Z4exitv(), !dbg !15
+  ret void, !dbg !16
+}
+
+declare void @_Z4exitv()
+
+; Function Attrs: noinline nounwind optnone uwtable mustprogress
+define dso_local signext i32 @_Z3foov() !dbg !17 {
+entry:
+  %0 = load i32, i32* @_ZL3var, align 16, !dbg !21
+  ret i32 %0, !dbg !22
+}
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!7, !8, !9, !10}
+!llvm.ident = !{!11}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "var", linkageName: "_ZL3var", scope: !2, file: !3, line: 2, type: !6, isLocal: true, isDefinition: true, align: 128)
+!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, producer: "clang version 13.0.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "t.cpp", directory: "./")
+!4 = !{}
+!5 = !{!0}
+!6 = !DIBasicType(name: "unsigned int", size: 32, encoding: DW_ATE_unsigned)
+!7 = !{i32 7, !"Dwarf Version", i32 4}
+!8 = !{i32 2, !"Debug Info Version", i32 3}
+!9 = !{i32 1, !"wchar_size", i32 4}
+!10 = !{i32 7, !"uwtable", i32 1}
+!11 = !{!"clang version 13.0.0"}
+!12 = distinct !DISubprogram(name: "f", linkageName: "_Z1fv", scope: !3, file: !3, line: 4, type: !13, scopeLine: 4, flags: DIFlagPrototyped | DIFlagNoReturn, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !4)
+!13 = !DISubroutineType(types: !14)
+!14 = !{null}
+!15 = !DILocation(line: 5, column: 1, scope: !12)
+!16 = !DILocation(line: 7, column: 1, scope: !12)
+!17 = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov", scope: !3, file: !3, line: 10, type: !18, scopeLine: 11, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !4)
+!18 = !DISubroutineType(types: !19)
+!19 = !{!20}
+!20 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!21 = !DILocation(line: 12, column: 18, scope: !17)
+!22 = !DILocation(line: 12, column: 11, scope: !17)
Index: llvm/lib/CodeGen/CommandFlags.cpp
===
--- llvm/lib/CodeGen/CommandFlags.cpp
+++ llvm/lib/CodeGen/CommandFlags.cpp
@@ -97,6 +97,7 @@
 CGOPT(bool, ValueTrackingVariableLocations)
 CGOPT(bool, ForceDwarfFrameSection)
 CGOPT(bool, XRayOmitFunctionIndex)
+CGOPT(bool, DebugStrictDwarf)
 
 codegen::RegisterCodeGenFlags::RegisterCodeGenFlags() {
 #define CGBINDOPT(NAME)\
@@ -471,6 +472,10 @@
   cl::init(false));
   CGBINDOPT(XRayOmitFunctionIndex);
 
+  static cl::opt DebugStrictDwarf(
+  "strict-dwarf", cl::desc("use strict dwarf"), cl::init(false));
+  CGBINDOPT(DebugStrictDwarf);
+
 #undef CGBINDOPT
 
   mc::RegisterMCTargetOptionsFlags();
@@ -567,6 +572,7 @@
   Options.ValueTrackingVariableLocations = getValueTrackingVariableLocations();
   Options.ForceDwarfFrameSection = getForceDwarfFrameSection();
   Options.XRayOmitFunctionIndex = getXRayOmitFunctionIndex();
+  Options.DebugStrictDwarf = getDebugStrictDwarf();
 
   Options.MCOptions = mc::InitMCTargetOptionsFromFlags();
 
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -137,6 +137,7 @@
   SupportsDebugEntryValues(false), EnableDebugEntryValues(false),

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits
shchenz added inline comments.



Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:398-399
+
+// Assertion for other cases.
+assert(true && "Tag is generated not following strict DWARF!");
+  }

dblaikie wrote:
> side note: Not sure what this assertion is for/does?
typo :) 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 344300.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

Files:
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as 
DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata 
!DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, 
producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, 
emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: 
None)
+!1 = !DIFile(filename: "1.cpp", directory: "./")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 3}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{i32 7, !"uwtable", i32 1}
+!7 = !{!"clang version 13.0.0"}
+!8 = distinct !DISubprogram(name: "foo", linkageName: "_Z3fooOi", scope: !1, 
file: !1, line: 1, type: !9, scopeLine: 2, flags: DIFlagPrototyped | 
DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: 
!0, retainedNodes: !13)
+!9 = !DISubroutineType(types: !10)
+!10 = !{null, !11}
+!11 = !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: !12, size: 
64)
+!12 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!13 = !{!14}
+!14 = !DILocalVariable(name: "i", arg: 1, scope: !8, file: !1, line: 1, type: 
!11)
+!15 = !DILocation(line: 0, scope: !8)
+!16 = !DILocation(line: 3, column: 1, scope: !8)
Index: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -386,6 +386,18 @@
 }
 
 DIE ::createAndAddDIE(dwarf::Tag Tag, DIE , const DINode *N) {
+  // For strict DWARF mode, only generate tags available to current DWARF
+  // version.
+  if (Asm->TM.Options.DebugStrictDwarf &&
+  DD->getDwarfVersion() < dwarf::TagVersion(Tag)) {
+// See if there is any replacement for some tags.
+if (Tag == dwarf::DW_TAG_rvalue_reference_type &&
+DD->getDwarfVersion() >= 3)
+  Tag = dwarf::DW_TAG_reference_type;
+else
+  // Assertion for other cases.
+  assert(false && "Tag is generated not following strict DWARF!");
+  }
   DIE  = Parent.addChild(DIE::get(DIEValueAllocator, Tag));
   if (N)
 insertDIE(N, );


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata !DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: None)
+!1 = !DIFile(filename: 

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

In D100630#2749594 , @dblaikie wrote:

> In D100630#2749550 , @shchenz wrote:
>
>> In D100630#2748899 , @dblaikie 
>> wrote:
>>
>>> Does this cause duplicate DW_TAG_reference_types in the output, if the 
>>> input IR Has both DW_TAG_reference_type and DW_TAG_rvalue_reference_types?
>>
>> Yes, it will cause such issue in theory. I can not cook a case that has a 
>> DW_TAG_reference_type to a DW_TAG_rvalue_reference_types or has a 
>> DW_TAG_rvalue_reference_types to a DW_TAG_reference_type for now. Is there 
>> such usage that we both be rvalue-reference and lvalue-reference to a basic 
>> type?
>
> Ah, I was less thinking of a case of an rvalue reference and a normal 
> reference in the same chain - I was thinking more about two unrelated 
> reference types.
>
> Try some code like:
>
>   void f1(int &, int ) {
>   }
>
> I'm guessing without this change - you get 'x's type pointing to the 
> rvalue_reference_type, 'y's type pointing to the reference_type, and both of 
> those pointing to the 'int' DW_TAG_basic_type.
>
> But with this change I'm worried you'll get two copies of the 
> DW_TAG_reference_type - one that replaces the rvalue reference, and then the 
> real one. Instead you should get one copy that both 'x' and 'y' refer to, I 
> think.

Hmm, yeah, indeed, a duplicated `DW_TAG_reference_type` is generated.

  0x0069:   DW_TAG_reference_type
  DW_AT_type  (0x006e "int")
  
  0x006e:   DW_TAG_base_type
  DW_AT_name  ("int")
  DW_AT_encoding  (DW_ATE_signed)
  DW_AT_byte_size (0x04)
  
  0x0075:   DW_TAG_reference_type
  DW_AT_type  (0x006e "int")

I think rather than fixing the duplicated `DW_TAG_reference_type` in the 
backend, maybe it is better to fix this strict DWARF issue in the FE like the 
fix in the previous patch https://reviews.llvm.org/D100630?id=338755

What do you think? @dblaikie


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

In D100630#2748899 , @dblaikie wrote:

> Does this cause duplicate DW_TAG_reference_types in the output, if the input 
> IR Has both DW_TAG_reference_type and DW_TAG_rvalue_reference_types?

Yes, it will cause such issue in theory. I can not cook a case that has a 
DW_TAG_reference_type to a DW_TAG_rvalue_reference_types or has a 
DW_TAG_rvalue_reference_types to a DW_TAG_reference_type for now. Is there such 
usage that we both be rvalue-reference and lvalue-reference to a basic type?




Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:391
+  // version.
+  dwarf::Tag FixedTag = (dwarf::Tag)Tag;
+  if (Asm->TM.Options.DebugStrictDwarf &&

dblaikie wrote:
> Rather than adding a cast here, perhaps the parameter type could be updated? 
> (maybe in a separate preliminary commit, though, so as not to muddy this one)
Add a new NFC patch D102207


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 344269.
shchenz marked an inline comment as done.
shchenz added a comment.

1: address @dblaikie comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

Files:
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as 
DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata 
!DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, 
producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, 
emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: 
None)
+!1 = !DIFile(filename: "1.cpp", directory: "./")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 3}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{i32 7, !"uwtable", i32 1}
+!7 = !{!"clang version 13.0.0"}
+!8 = distinct !DISubprogram(name: "foo", linkageName: "_Z3fooOi", scope: !1, 
file: !1, line: 1, type: !9, scopeLine: 2, flags: DIFlagPrototyped | 
DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: 
!0, retainedNodes: !13)
+!9 = !DISubroutineType(types: !10)
+!10 = !{null, !11}
+!11 = !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: !12, size: 
64)
+!12 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!13 = !{!14}
+!14 = !DILocalVariable(name: "i", arg: 1, scope: !8, file: !1, line: 1, type: 
!11)
+!15 = !DILocation(line: 0, scope: !8)
+!16 = !DILocation(line: 3, column: 1, scope: !8)
Index: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -386,6 +386,18 @@
 }
 
 DIE ::createAndAddDIE(dwarf::Tag Tag, DIE , const DINode *N) {
+  // For strict DWARF mode, only generate tags available to current DWARF
+  // version.
+  if (Asm->TM.Options.DebugStrictDwarf &&
+  DD->getDwarfVersion() < dwarf::TagVersion(Tag)) {
+// See if there is any replacement for some tags.
+if (Tag == dwarf::DW_TAG_rvalue_reference_type &&
+DD->getDwarfVersion() >= 3)
+  Tag = dwarf::DW_TAG_reference_type;
+
+// Assertion for other cases.
+assert(true && "Tag is generated not following strict DWARF!");
+  }
   DIE  = Parent.addChild(DIE::get(DIEValueAllocator, Tag));
   if (N)
 insertDIE(N, );


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata !DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, 

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-10 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

In D100630#2745272 , @dblaikie wrote:

> Mixed feelings - is this the only place where we're changing behavior for 
> strict-DWARF in the frontend/clang? (maybe it'd be better to do it all in the 
> same place, down in the backend when the IR is mapped to actual DWARF)

Update the patch to do the check down in the backend. Seems we already have one 
centralized interface for TAGs generation.

> @aprantl @probinson - you two have any thoughts on this layering aspect?
>
> I think for CodeView we make some different choices up in the frontend (& 
> completely different implementations in the backend), so it's not totally 
> unreasonable, but curious how folks feel.

Welcome your comments! @aprantl @probinson


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-10 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 343983.
shchenz added a comment.
Herald added subscribers: llvm-commits, hiraditya, nemanjai.
Herald added a project: LLVM.

update according to @dblaikie comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

Files:
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as 
DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata 
!DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, 
producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, 
emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: 
None)
+!1 = !DIFile(filename: "1.cpp", directory: "./")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 3}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{i32 7, !"uwtable", i32 1}
+!7 = !{!"clang version 13.0.0"}
+!8 = distinct !DISubprogram(name: "foo", linkageName: "_Z3fooOi", scope: !1, 
file: !1, line: 1, type: !9, scopeLine: 2, flags: DIFlagPrototyped | 
DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: 
!0, retainedNodes: !13)
+!9 = !DISubroutineType(types: !10)
+!10 = !{null, !11}
+!11 = !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: !12, size: 
64)
+!12 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!13 = !{!14}
+!14 = !DILocalVariable(name: "i", arg: 1, scope: !8, file: !1, line: 1, type: 
!11)
+!15 = !DILocation(line: 0, scope: !8)
+!16 = !DILocation(line: 3, column: 1, scope: !8)
Index: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -386,7 +386,20 @@
 }
 
 DIE ::createAndAddDIE(unsigned Tag, DIE , const DINode *N) {
-  DIE  = Parent.addChild(DIE::get(DIEValueAllocator, (dwarf::Tag)Tag));
+  // For strict DWARF mode, only generate tags available to current DWARF
+  // version.
+  dwarf::Tag FixedTag = (dwarf::Tag)Tag;
+  if (Asm->TM.Options.DebugStrictDwarf &&
+  DD->getDwarfVersion() < dwarf::TagVersion(FixedTag)) {
+// See if there is any replacement for some tags.
+if (FixedTag == dwarf::DW_TAG_rvalue_reference_type &&
+DD->getDwarfVersion() >= 3)
+  FixedTag = dwarf::DW_TAG_reference_type;
+
+// Assertion for other cases.
+assert(true && "Tag is generated not following strict DWARF!");
+  }
+  DIE  = Parent.addChild(DIE::get(DIEValueAllocator, FixedTag));
   if (N)
 insertDIE(N, );
   return Die;


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata !DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = 

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-07 Thread ChenZheng via Phabricator via cfe-commits
shchenz added a comment.

gentle ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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


[PATCH] D100826: [Debug-Info][NFC] add -gstrict-dwarf support in backend

2021-04-23 Thread ChenZheng via Phabricator via cfe-commits
shchenz updated this revision to Diff 339840.
shchenz added a comment.

1: put test cases in single file


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100826

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/test/DebugInfo/PowerPC/strict-dwarf.ll

Index: llvm/test/DebugInfo/PowerPC/strict-dwarf.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf.ll
@@ -0,0 +1,60 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s
+
+; FIXME: when -strict-dwarf=true is specified, we should check "STRICT" to tell
+; that with DWARF 4, we should not generate DWARF 5 attribute DW_AT_noreturn and
+; DW_AT_alignment.
+
+; CHECK: DW_AT_alignment
+; CHECK: DW_AT_noreturn
+; STRICT-NOT: DW_AT_noreturn
+; STRICT-NOT: DW_AT_alignment
+
+@_ZL3var = internal global i32 0, align 16, !dbg !0
+
+; Function Attrs: noinline noreturn optnone uwtable mustprogress
+define dso_local void @_Z1fv() #0 !dbg !12 {
+entry:
+  call void @_Z4exitv(), !dbg !15
+  ret void, !dbg !16
+}
+
+declare void @_Z4exitv()
+
+; Function Attrs: noinline nounwind optnone uwtable mustprogress
+define dso_local signext i32 @_Z3foov() !dbg !17 {
+entry:
+  %0 = load i32, i32* @_ZL3var, align 16, !dbg !21
+  ret i32 %0, !dbg !22
+}
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!7, !8, !9, !10}
+!llvm.ident = !{!11}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "var", linkageName: "_ZL3var", scope: !2, file: !3, line: 2, type: !6, isLocal: true, isDefinition: true, align: 128)
+!2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, producer: "clang version 13.0.0", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "t.cpp", directory: "./")
+!4 = !{}
+!5 = !{!0}
+!6 = !DIBasicType(name: "unsigned int", size: 32, encoding: DW_ATE_unsigned)
+!7 = !{i32 7, !"Dwarf Version", i32 4}
+!8 = !{i32 2, !"Debug Info Version", i32 3}
+!9 = !{i32 1, !"wchar_size", i32 4}
+!10 = !{i32 7, !"uwtable", i32 1}
+!11 = !{!"clang version 13.0.0"}
+!12 = distinct !DISubprogram(name: "f", linkageName: "_Z1fv", scope: !3, file: !3, line: 4, type: !13, scopeLine: 4, flags: DIFlagPrototyped | DIFlagNoReturn, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !4)
+!13 = !DISubroutineType(types: !14)
+!14 = !{null}
+!15 = !DILocation(line: 5, column: 1, scope: !12)
+!16 = !DILocation(line: 7, column: 1, scope: !12)
+!17 = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov", scope: !3, file: !3, line: 10, type: !18, scopeLine: 11, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !2, retainedNodes: !4)
+!18 = !DISubroutineType(types: !19)
+!19 = !{!20}
+!20 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!21 = !DILocation(line: 12, column: 18, scope: !17)
+!22 = !DILocation(line: 12, column: 11, scope: !17)
Index: llvm/lib/CodeGen/CommandFlags.cpp
===
--- llvm/lib/CodeGen/CommandFlags.cpp
+++ llvm/lib/CodeGen/CommandFlags.cpp
@@ -97,6 +97,7 @@
 CGOPT(bool, ValueTrackingVariableLocations)
 CGOPT(bool, ForceDwarfFrameSection)
 CGOPT(bool, XRayOmitFunctionIndex)
+CGOPT(bool, DebugStrictDwarf)
 
 codegen::RegisterCodeGenFlags::RegisterCodeGenFlags() {
 #define CGBINDOPT(NAME)\
@@ -471,6 +472,10 @@
   cl::init(false));
   CGBINDOPT(XRayOmitFunctionIndex);
 
+  static cl::opt DebugStrictDwarf(
+  "strict-dwarf", cl::desc("use strict dwarf"), cl::init(false));
+  CGBINDOPT(DebugStrictDwarf);
+
 #undef CGBINDOPT
 
   mc::RegisterMCTargetOptionsFlags();
@@ -567,6 +572,7 @@
   Options.ValueTrackingVariableLocations = getValueTrackingVariableLocations();
   Options.ForceDwarfFrameSection = getForceDwarfFrameSection();
   Options.XRayOmitFunctionIndex = getXRayOmitFunctionIndex();
+  Options.DebugStrictDwarf = getDebugStrictDwarf();
 
   Options.MCOptions = mc::InitMCTargetOptionsFromFlags();
 
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -141,6 +141,7 @@
   SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
   PseudoProbeForProfiling(false), ValueTrackingVariableLocations(false),
   ForceDwarfFrameSection(false), XRayOmitFunctionIndex(false),
+   

[PATCH] D100809: [Debug-Info] implement -gstrict-dwarf

2021-04-22 Thread ChenZheng via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG26f138eed4af: [Debug-Info] implement -gstrict-dwarf 
(authored by shchenz).

Changed prior to commit:
  https://reviews.llvm.org/D100809?vs=338752=339464#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100809

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/debug-options.c


Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -110,6 +110,18 @@
 // RUN: %clang -### -c -g %s -target powerpc64-ibm-aix-xcoff 2>&1 \
 // RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_DBX %s
 
+// For DBX, -g defaults to -gstrict-dwarf.
+// RUN: %clang -### -c -g %s -target powerpc-ibm-aix-xcoff 2>&1 \
+// RUN: | FileCheck -check-prefix=STRICT %s
+// RUN: %clang -### -c -g %s -target powerpc64-ibm-aix-xcoff 2>&1 \
+// RUN: | FileCheck -check-prefix=STRICT %s
+// RUN: %clang -### -c -g -gno-strict-dwarf %s -target powerpc-ibm-aix-xcoff \
+// RUN: 2>&1 | FileCheck -check-prefix=NOSTRICT %s
+// RUN: %clang -### -c -g %s -target x86_64-linux-gnu 2>&1 \
+// RUN: | FileCheck -check-prefix=NOSTRICT %s
+// RUN: %clang -### -c -g -ggdb %s -target powerpc-ibm-aix-xcoff 2>&1 \
+// RUN: | FileCheck -check-prefix=NOSTRICT %s
+
 // On the AIX, -g defaults to -gno-column-info.
 // RUN: %clang -### -c -g %s -target powerpc-ibm-aix-xcoff 2>&1 \
 // RUN: | FileCheck -check-prefix=NOCI %s
@@ -314,6 +326,9 @@
 // G_SCE:  "-debugger-tuning=sce"
 // G_DBX:  "-debugger-tuning=dbx"
 //
+// STRICT:  "-gstrict-dwarf"
+// NOSTRICT-NOT:  "-gstrict-dwarf"
+//
 // G_NOTUNING: "-cc1"
 // G_NOTUNING-NOT: "-debugger-tuning="
 //
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3962,7 +3962,14 @@
   DebugInfoKind == codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::NoDebugInfo;
 
-  // We ignore flag -gstrict-dwarf for now.
+  // strict DWARF is set to false by default. But for DBX, we need it to be set
+  // as true by default.
+  if (const Arg *A = Args.getLastArg(options::OPT_gstrict_dwarf))
+(void)checkDebugInfoOption(A, Args, D, TC);
+  if (Args.hasFlag(options::OPT_gstrict_dwarf, options::OPT_gno_strict_dwarf,
+   DebuggerTuning == llvm::DebuggerKind::DBX))
+CmdArgs.push_back("-gstrict-dwarf");
+
   // And we handle flag -grecord-gcc-switches later with DWARFDebugFlags.
   Args.ClaimAllArgs(options::OPT_g_flags_Group);
 
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2788,8 +2788,10 @@
   Group;
 def : Flag<["-"], "grecord-gcc-switches">, Alias;
 def : Flag<["-"], "gno-record-gcc-switches">, Alias;
-def gstrict_dwarf : Flag<["-"], "gstrict-dwarf">, Group;
-def gno_strict_dwarf : Flag<["-"], "gno-strict-dwarf">, Group;
+defm strict_dwarf : BoolOption<"g", "strict-dwarf",
+  CodeGenOpts<"DebugStrictDwarf">, DefaultFalse,
+  PosFlag, NegFlag, BothFlags<[CoreOption]>>,
+  Group;
 defm column_info : BoolOption<"g", "column-info",
   CodeGenOpts<"DebugColumnInfo">, DefaultTrue,
   NegFlag, PosFlag, BothFlags<[CoreOption]>>,
Index: clang/include/clang/Basic/CodeGenOptions.def
===
--- clang/include/clang/Basic/CodeGenOptions.def
+++ clang/include/clang/Basic/CodeGenOptions.def
@@ -293,6 +293,7 @@
 VALUE_CODEGENOPT(StackProbeSize, 32, 4096) ///< Overrides default stack
///< probe size, even if 0.
 CODEGENOPT(NoStackArgProbe, 1, 0) ///< Set when -mno-stack-arg-probe is used
+CODEGENOPT(DebugStrictDwarf, 1, 1) ///< Whether or not to use strict DWARF 
info.
 CODEGENOPT(DebugColumnInfo, 1, 0) ///< Whether or not to use column information
   ///< in debug info.
 
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -3546,6 +3546,8 @@
 
 .. option:: -gstrict-dwarf, -gno-strict-dwarf
 
+Restrict DWARF features to those defined in the specified version, avoiding 
features from later versions.
+
 .. option:: -gz=, -gz (equivalent to -gz=zlib)
 
 DWARF debug sections compression type


Index: clang/test/Driver/debug-options.c

  1   2   >