Page MenuHomePhabricator

umesh.kalappa0 (Umesh Kalappa)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 17 2016, 2:03 AM (275 w, 6 d)

Recent Activity

Sep 2 2021

umesh.kalappa0 added a comment to D108421: Mark openmp internal global dso_local.

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.

Sep 2 2021, 9:46 PM · Restricted Project, Restricted Project, Restricted Project

May 26 2021

umesh.kalappa0 added inline comments to D103131: support debug info for alias variable.
May 26 2021, 12:07 AM · debug-info, Restricted Project, Restricted Project

May 25 2021

umesh.kalappa0 added inline comments to D103131: support debug info for alias variable.
May 25 2021, 11:33 PM · debug-info, Restricted Project, Restricted Project

Dec 22 2020

umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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
Dec 22 2020, 3:44 AM · Restricted Project, debug-info
umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Dec 22 2020, 3:43 AM · Restricted Project, debug-info

Dec 8 2020

umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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

Dec 8 2020, 7:32 AM · Restricted Project, debug-info

Nov 9 2020

umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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

Nov 9 2020, 8:53 PM · Restricted Project, debug-info

Oct 27 2020

umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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"

Oct 27 2020, 6:23 AM · Restricted Project, debug-info
umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Oct 27 2020, 6:22 AM · Restricted Project, debug-info

Oct 9 2020

umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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.

Oct 9 2020, 3:01 AM · Restricted Project, debug-info

Oct 6 2020

umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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

Oct 6 2020, 9:22 PM · Restricted Project, debug-info

Oct 5 2020

umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Oct 5 2020, 2:46 AM · Restricted Project, debug-info

Oct 2 2020

umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Oct 2 2020, 10:32 PM · Restricted Project, debug-info
umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Oct 2 2020, 4:42 AM · Restricted Project, debug-info

Oct 1 2020

umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Oct 1 2020, 8:31 AM · Restricted Project, debug-info
umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Oct 1 2020, 8:26 AM · Restricted Project, debug-info

Sep 25 2020

umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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).

Sep 25 2020, 7:56 AM · Restricted Project, debug-info

Sep 16 2020

umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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

Sep 16 2020, 10:00 PM · Restricted Project, debug-info
umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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?

Sep 16 2020, 5:58 AM · Restricted Project, debug-info
umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Sep 16 2020, 5:55 AM · Restricted Project, debug-info

Sep 15 2020

umesh.kalappa0 updated subscribers of D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

Hi All,

Sep 15 2020, 4:53 AM · Restricted Project, debug-info

Sep 14 2020

umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Sep 14 2020, 10:00 PM · Restricted Project, debug-info
umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Sep 14 2020, 5:29 AM · Restricted Project, debug-info
umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Sep 14 2020, 5:28 AM · Restricted Project, debug-info

Sep 13 2020

umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Sep 13 2020, 7:52 PM · Restricted Project, debug-info
umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Sep 13 2020, 7:25 AM · Restricted Project, debug-info

Sep 12 2020

umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Sep 12 2020, 1:29 AM · Restricted Project, debug-info
umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

extern int i;
int i;

Sep 12 2020, 12:43 AM · Restricted Project, debug-info

Sep 11 2020

umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Sep 11 2020, 12:51 AM · Restricted Project, debug-info

Sep 10 2020

umesh.kalappa0 added a comment to D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

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

Sep 10 2020, 2:34 AM · Restricted Project, debug-info
umesh.kalappa0 updated the diff for D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.

Testcase added.

Sep 10 2020, 2:33 AM · Restricted Project, debug-info

Sep 4 2020

umesh.kalappa0 requested review of D87147: PR-47391 : Two DIFile entries are describing the same file two different ways.
Sep 4 2020, 8:43 AM · Restricted Project, debug-info

Nov 30 2019

umesh.kalappa0 added a comment to D70696: [DebugInfo] Support to emit debugInfo for extern variables.

cat extern.c
int global_var = 2;

Nov 30 2019, 6:31 AM · Restricted Project, Restricted Project, debug-info

Sep 9 2019

umesh.kalappa0 created D67346: Bug 43202 - ARM FastIsel is renaming the memcpy to memcpy.<random-number> in getLibcallReg()..
Sep 9 2019, 4:03 AM · Restricted Project