@nikic ,is that changes are ok ?

In D142872#4093093, @nikic wrote:

@umesh.kalappa0 This issue should be fixed by https://github.com/llvm/llvm-project/commit/5f01a626dd0615df49773d419c75aeb33666ee83. Can you please give it another try?

In D142872#4090304, @nikic wrote:

CreateConstArrayGEP currently always creates an inbounds GEP. You need to modify it make inbounds optional or use a different method, not suppress it in the constant folding infrastructure.

Thank you very much for the feedback and

In D142872#4090317, @nikic wrote:

You also shouldn't need to introduce any new handling for the fwrapv option. I'm not sure how exactly it is currently threaded through, but there must be existing handling for it already. For example, there is isSignedOverflowDefined() on LangOptions.

@efriedma ,can you commit the same please ,since we don't have the commit access ?

fixed the testcase to adhere changes.

In D127495#3582591, @chmeee wrote:

In D127495#3581809, @umesh.kalappa0 wrote:

@chmeee ,Can you commit for us ,since we don't have the commit access for the repo.

Sorry, but my computer with the relevant keys is in storage for a pending move, so I won't be able to commit for a month or so. @nemanjai is better positioned to do it.

@chmeee ,Can you commit for us ,since we don't have the commit access for the repo.

@chmee and @nemanjai . ,Please do you have any other comments or ok to commit the same ?

LGTM too.

In D123997#3463602, @nemanjai wrote:

In D123997#3461035, @umesh.kalappa0 wrote:

@nemanjai ,thank you for quick fix and please checkout the unit test failed ?

The unit test failure should be unrelated. A change in code generation for PowerPC should not cause a sanitizer failure on X86.

@nemanjai ,thank you for quick fix and please checkout the unit test failed ?

In D108421#2977216, @MaskRay wrote:

In D108421#2977107, @kamleshbhalui wrote:

In D108421#2958848, @MaskRay wrote:

If you read the comment in TargetMachine::shouldAssumeDSOLocal: this is the wrong direction. dso_local is assumed to be marked by the frontend.

Direct accesses and GOT accesses are trade-offs. Direct accesses are not always preferred. The MachO special case is an unfortunate case for their xnu kernel, not a good example here.

@MaskRay I would like to know more about these trade-offs details, any supporting documents will do.
Considering below testcase, can you shed some light how code generated by llc-12 is better than llc-11 for given testcase?
https://godbolt.org/z/x9xojWb58

This is a very minor issue. First, global variable access is rarely a performance bottleneck.
Second, if the symbol turns out to be non-preemptible (which implies that it is defined in the component), the R_X86_64_REX_GOTPCRELX GOT indirection can be optimized out.
The only minor issue is slightly longer code sequence.

And FYI this testcase does not work when build as Linux Kernel Module. LKM loader throw error("Unknown rela relocation: 42")?

This is a kernel issue. Please mention the justification (is it related to OpenMP?) in the first place.
The kernel can be compiled in -fpie mode. In this mode, taking the address of a default-visibility undefined symbol uses R_X86_64_REX_GOTPCRELX.
So the kernel should support R_X86_64_REX_GOTPCRELX anyway.

---

If we think the optimization is meaningful:

Depending on the property of .gomp_critical_user_.atomic_reduction.var different DSOLocal strategies should be used.
If it is TU-local, make it local linkage. If it is linked image local, make it hidden visibility.
If it may be defined in a shared object and shared with other shared objects or the main executable, (not so sure because such symbol interposition does not work in other binary formats), use dso_preemptable as is.

I believe the current forced dso_local is definitely incorrect because it may break -fpic -shared links.

@kamleshbhalui ,make the changes accordingly that honour -fpic and don't mark dsolocal in this case.

In D87147#2440814, @dblaikie wrote:

Does this pass "check-clang" for you? I tried applying the patch and got a lot of failures - crashes like this:

$ ninja check-clang-codegenopencl
[0/1] Running lit suite /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL
llvm-lit: /usr/local/google/home/blaikie/dev/llvm/src/llvm/utils/lit/lit/llvm/config.py:347: note: using clang: /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang
FAIL: Clang :: CodeGenOpenCL/enqueue-kernel-non-entry-block.cl (105 of 107)
******************** TEST 'Clang :: CodeGenOpenCL/enqueue-kernel-non-entry-block.cl' FAILED ********************
Script:
--
: 'RUN: at line 1';   /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -emit-llvm -o - -triple amdgcn < /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl | /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=COMMON,AMDGPU
: 'RUN: at line 2';   /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -emit-llvm -o - -triple "spir-unknown-unknown" < /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl | /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=COMMON,SPIR32
: 'RUN: at line 3';   /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -emit-llvm -o - -triple "spir64-unknown-unknown" < /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl | /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=COMMON,SPIR64
: 'RUN: at line 4';   /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -debug-info-kind=limited -gno-column-info -emit-llvm -o - -triple amdgcn < /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl | /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=CHECK-DEBUG
--
Exit Code: 2

Command Output (stderr):
--
clang: /usr/local/google/home/blaikie/dev/llvm/src/clang/include/clang/Basic/SourceLocation.h:327: const char *clang::PresumedLoc::getFilename() const: Assertion `isValid()' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -debug-info-kind=limited -gno-column-info -emit-llvm -o - -triple amdgcn
1.      <eof> parser at end of file
2.      <stdin>:11:13: LLVM IR generation of declaration 'test'
3.      <stdin>:11:13: Generating code for declaration 'test'
 #0 0x00000000095c28aa llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Unix/Signals.inc:563:11
 #1 0x00000000095c2a7b PrintStackTraceSignalHandler(void*) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Unix/Signals.inc:630:1
 #2 0x00000000095c109b llvm::sys::RunSignalHandlers() /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Signals.cpp:70:5
 #3 0x00000000095c31ad SignalHandler(int) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Unix/Signals.inc:405:1
 #4 0x00007feb7a44b140 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
 #5 0x00007feb79f1bdb1 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:51:1
 #6 0x00007feb79f05537 abort ./stdlib/abort.c:81:7
 #7 0x00007feb79f0540f get_sysdep_segment_value ./intl/loadmsgcat.c:509:8
 #8 0x00007feb79f0540f _nl_load_domain ./intl/loadmsgcat.c:970:34
 #9 0x00007feb79f145b2 (/lib/x86_64-linux-gnu/libc.so.6+0x345b2)
#10 0x00000000098b610d clang::PresumedLoc::getFilename() const /usr/local/google/home/blaikie/dev/llvm/src/clang/include/clang/Basic/SourceLocation.h:0:5
#11 0x0000000009a92785 clang::CodeGen::CGDebugInfo::getOrCreateFile(clang::SourceLocation) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:409:24
#12 0x0000000009a98e71 clang::CodeGen::CGDebugInfo::CreateType(clang::TypedefType const*, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:1213:69
#13 0x0000000009aa3c45 clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3253:5
#14 0x0000000009a93172 clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3173:17
#15 0x0000000009a971fc clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:905:5
#16 0x0000000009aa3a8b clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3220:5
#17 0x0000000009a93172 clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3173:17
#18 0x0000000009aa8d97 clang::CodeGen::CGDebugInfo::EmitDeclare(clang::VarDecl const*, llvm::Value*, llvm::Optional<unsigned int>, clang::CodeGen::CGBuilderTy&, bool) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:4179:8
#19 0x0000000009aa99fb clang::CodeGen::CGDebugInfo::EmitDeclareOfAutoVariable(clang::VarDecl const*, llvm::Value*, clang::CodeGen::CGBuilderTy&, bool) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:4298:3
#20 0x0000000009d8ffc3 clang::CodeGen::CodeGenFunction::EmitAutoVarAlloca(clang::VarDecl const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDecl.cpp:1609:7
#21 0x0000000009d8c8a8 clang::CodeGen::CodeGenFunction::EmitAutoVarDecl(clang::VarDecl const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDecl.cpp:0:30
#22 0x0000000009d8c0d5 clang::CodeGen::CodeGenFunction::EmitVarDecl(clang::VarDecl const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDecl.cpp:209:1
#23 0x0000000009d8bd87 clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDecl.cpp:154:49
#24 0x0000000009ed97b6 clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGStmt.cpp:1249:22
#25 0x0000000009ed2463 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGStmt.cpp:387:5
#26 0x0000000009ed170e clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGStmt.cpp:55:7
#27 0x0000000009eda7bd clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGStmt.cpp:441:3
#28 0x0000000009d32c61 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenFunction.cpp:1183:5
#29 0x0000000009d33713 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenFunction.cpp:1354:3
#30 0x0000000009be99e1 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenModule.cpp:4715:3
#31 0x0000000009be069d clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenModule.cpp:3065:12
#32 0x0000000009be544e clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenModule.cpp:2818:5
#33 0x0000000009bed590 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenModule.cpp:5533:38
#34 0x000000000a6d0c82 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/ModuleBuilder.cpp:169:73
#35 0x000000000a6cadc4 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenAction.cpp:218:12
#36 0x000000000d10feef clang::ParseAST(clang::Sema&, bool, bool) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/Parse/ParseAST.cpp:162:20
#37 0x000000000a4f417d clang::ASTFrontendAction::ExecuteAction() /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/Frontend/FrontendAction.cpp:1058:1
#38 0x000000000a6c77e5 clang::CodeGenAction::ExecuteAction() /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenAction.cpp:1153:1
#39 0x000000000a4f3b48 clang::FrontendAction::Execute() /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/Frontend/FrontendAction.cpp:953:7
#40 0x000000000a410dd8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/Frontend/CompilerInstance.cpp:991:23
#41 0x000000000a6b3f54 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278:8
#42 0x00000000061eaa2c cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /usr/local/google/home/blaikie/dev/llvm/src/clang/tools/driver/cc1_main.cpp:240:13
#43 0x00000000061dd2fa ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /usr/local/google/home/blaikie/dev/llvm/src/clang/tools/driver/driver.cpp:330:5
#44 0x00000000061dc49d main /usr/local/google/home/blaikie/dev/llvm/src/clang/tools/driver/driver.cpp:407:5
#45 0x00007feb79f06cca __libc_start_main ./csu/../csu/libc-start.c:308:16
#46 0x00000000061dbc4a _start (/usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang+0x61dbc4a)
FileCheck error: '<stdin>' is empty.
FileCheck command line:  /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=CHECK-DEBUG

In D87147#2367384, @dblaikie wrote:

@aprantl could you check this over? It seems plausibly correct to me but I don't know this code too well.

@aprantl ,Please do let us know your comments on the change ????

In D87147#2355466, @dblaikie wrote:

Few unaddressed comments and could use some formatting (try clang-tidy, you can have it format just the parts of the file you changed by using .../clang/tools/clang-format/git-clang-format origin for instance)

Updated with "clang-format -lines=406:436"

In D87147#2319776, @dblaikie wrote:

I'm not sure the FID changes have any effect? It looks like this code may be the same as/equivalent to the previous version:

if (Loc.isInvalid() &&  FileName.empty()){
  FileName = TheCU->getFile()->getFilename();
}

& maybe that's fine? It does seem a bit strange to me that we wouldn't produce a checksum for this particular file, though.

@dblaikie and @aprantl ,please let us know your suggestions on the latest change .

In D87147#2288103, @dblaikie wrote:

In D87147#2288024, @aprantl wrote:

I think the comment in https://reviews.llvm.org/rL349065 describes it quite well:

The DIFile used by the CU is special and distinct from the main source
file. Its directory part specifies what becomes the DW_AT_comp_dir
(the compilation directory), even if the source file was specified
with an absolute path.

So while the CU links to a DIFile it's more a storage mechanism for DW_AT_comp_dir and not a "file" in the normal sense and thus should be treated special. (And we might want to just store a string instead to avoid this confusion in the future.

Fair points.

@umesh.kalappa0 is there specific observable behavior of the resulting DWARF you were trying to address (I seem to recall/think there was)? Or only the quirky/strange IR representation?

@dblaikie ,like stated in https://bugs.llvm.org/show_bug.cgi?id=47391 ,we are trying to address the specific behavior, where the debug_line referring to two different file index's (1 and 2).

In D87147#2277138, @dblaikie wrote:

In D87147#2276547, @umesh.kalappa0 wrote:

In D87147#2275685, @dblaikie wrote:

Hmm, sorry for the churn here - I was going to commit this, but looking at it, it seems this patch pretty much exactly undoes the work from rL349065 - @aprantl can you weigh in on this? This patch doesn't seem to break your test - did your test test the issue correctly? Maybe some other change that's happened since your change has made reverting it viable while preserving the desired behavior?

thank you @dblaikie for commiting this.

Sorry, to clarify, this patch hasn't been committed yet - hoping @aprantl can chime in with some context for the original change that this patch is reverting.

@aprantl and @dblaikie ,sure we will wait for your confirmation

In D87147#2275685, @dblaikie wrote:

Hmm, sorry for the churn here - I was going to commit this, but looking at it, it seems this patch pretty much exactly undoes the work from rL349065 - @aprantl can you weigh in on this? This patch doesn't seem to break your test - did your test test the issue correctly? Maybe some other change that's happened since your change has made reverting it viable while preserving the desired behavior?

Hi All,

extern int i;
int i;

In D87147#2257226, @dblaikie wrote:

This'll need a test case. (& any idea if there are other instances of denormalized DIFiles that could cause duplicates?)

Testcase added.

cat extern.c
int global_var = 2;