yaxunl (Yaxun Liu)
User

Projects

User does not belong to any projects.

User Details

User Since
May 13 2015, 10:16 AM (144 w, 5 d)

Recent Activity

Thu, Feb 15

yaxunl committed rC325279: Clean up AMDGCN tests.
Clean up AMDGCN tests
Thu, Feb 15, 11:14 AM
yaxunl committed rL325279: Clean up AMDGCN tests.
Clean up AMDGCN tests
Thu, Feb 15, 11:14 AM
yaxunl closed D43340: Clean up AMDGCN tests.
Thu, Feb 15, 11:14 AM
yaxunl added a comment to D34367: CodeGen: Fix address space of indirect function argument.

That's not really okay; there are some places that make guarantees about call-argument ordering, and in general we want that to be decided at a higher level, rather than having a particular order forced in corner cases just to satisfy a lower-level implementation requirement.

Thu, Feb 15, 11:07 AM
yaxunl added a comment to D43340: Clean up AMDGCN tests.

LGTM Plus I think there was a test with giz in its name. Should that be renamed?

Thu, Feb 15, 10:33 AM
yaxunl created D43340: Clean up AMDGCN tests.
Thu, Feb 15, 9:46 AM
yaxunl committed rC325264: [OpenCL] Fix __enqueue_block for block with captures.
[OpenCL] Fix __enqueue_block for block with captures
Thu, Feb 15, 8:41 AM
yaxunl committed rL325264: [OpenCL] Fix __enqueue_block for block with captures.
[OpenCL] Fix __enqueue_block for block with captures
Thu, Feb 15, 8:41 AM
yaxunl closed D43240: [OpenCL] Fix __enqueue_block for block with captures.
Thu, Feb 15, 8:41 AM
yaxunl added a comment to D43240: [OpenCL] Fix __enqueue_block for block with captures.

LGTM! Thanks for looking at this. Just one thing, I was wondering whether it would be cleaner way if we extend test/CodeGenOpenCL/cl20-device-side-enqueue.cl instead of adding a new one here? Because this is the test that is meant to exercise all DSE codegen bits. Perhaps we can modify one block in that test to have the same format as here (i.e. using captures), since now we test the same block there most of the time. However, we don't test any of kernel wrapper *_block_invoke_kernel there. Not sure why...

Thu, Feb 15, 6:48 AM
yaxunl added inline comments to D34367: CodeGen: Fix address space of indirect function argument.
Thu, Feb 15, 6:26 AM
yaxunl updated the diff for D34367: CodeGen: Fix address space of indirect function argument.

Revised by John's comments. Removed address space from CallArg and added l-value expression instead.

Thu, Feb 15, 6:22 AM

Tue, Feb 13

yaxunl updated the diff for D42800: Let CUDA toolchain support amdgpu target.

Update with Greg's change.

Tue, Feb 13, 1:33 PM
yaxunl committed rC325031: [AMDGPU] Change constant addr space to 4.
[AMDGPU] Change constant addr space to 4
Tue, Feb 13, 10:03 AM
yaxunl committed rL325031: [AMDGPU] Change constant addr space to 4.
[AMDGPU] Change constant addr space to 4
Tue, Feb 13, 10:03 AM
yaxunl closed D43171: [AMDGPU] Change constant addr space to 4 for clang.
Tue, Feb 13, 10:03 AM
yaxunl closed D43171: [AMDGPU] Change constant addr space to 4 for clang.
Tue, Feb 13, 10:03 AM
yaxunl committed rL325030: [AMDGPU] Change constant addr space to 4.
[AMDGPU] Change constant addr space to 4
Tue, Feb 13, 10:03 AM
yaxunl closed D43170: [AMDGPU] Change constant addr space to 4.
Tue, Feb 13, 10:02 AM
yaxunl added a comment to D43170: [AMDGPU] Change constant addr space to 4.

Will clean up the old addr space mapping with separate patch.

Tue, Feb 13, 8:42 AM
yaxunl added inline comments to D43171: [AMDGPU] Change constant addr space to 4 for clang.
Tue, Feb 13, 8:32 AM
yaxunl created D43240: [OpenCL] Fix __enqueue_block for block with captures.
Tue, Feb 13, 8:08 AM

Sun, Feb 11

yaxunl created D43171: [AMDGPU] Change constant addr space to 4 for clang.
Sun, Feb 11, 1:11 PM
yaxunl created D43170: [AMDGPU] Change constant addr space to 4.
Sun, Feb 11, 1:09 PM

Thu, Feb 8

yaxunl accepted D43078: Fix crash on array initializer with non-0 alloca addrspace.

LGTM. Thanks!

Thu, Feb 8, 11:11 AM
yaxunl closed D43030: Update AMDGPU documentation about address space.

committed.

Thu, Feb 8, 11:04 AM
yaxunl committed rL324617: [AMDGPU] Updae documentation about address space.
[AMDGPU] Updae documentation about address space
Thu, Feb 8, 7:44 AM

Wed, Feb 7

yaxunl updated the diff for D43030: Update AMDGPU documentation about address space.

Removed amdgiz and amdgizcl.

Wed, Feb 7, 11:36 AM
yaxunl created D43030: Update AMDGPU documentation about address space.
Wed, Feb 7, 10:36 AM

Mon, Feb 5

yaxunl added inline comments to D42800: Let CUDA toolchain support amdgpu target.
Mon, Feb 5, 10:41 AM

Fri, Feb 2

yaxunl committed rL324101: [AMDGPU] Switch to the new addr space mapping by default.
[AMDGPU] Switch to the new addr space mapping by default
Fri, Feb 2, 8:11 AM
yaxunl committed rC324102: [AMDGPU] Switch to the new addr space mapping by default.
[AMDGPU] Switch to the new addr space mapping by default
Fri, Feb 2, 8:10 AM
yaxunl committed rL324102: [AMDGPU] Switch to the new addr space mapping by default.
[AMDGPU] Switch to the new addr space mapping by default
Fri, Feb 2, 8:10 AM
yaxunl closed D40955: [AMDGPU] Make the new addr space mapping default.
Fri, Feb 2, 8:10 AM
yaxunl closed D40956: [AMDGPU] Switch to the new addr space mapping by default for clang.
Fri, Feb 2, 8:10 AM

Thu, Feb 1

yaxunl added a comment to D42800: Let CUDA toolchain support amdgpu target.

Only commenting on parts that I'm a bit familiar with. In general, does it make sense to split this patch, are there different "stages" of support? Like 1) being able to compile an empty file, 2) generate optimized code, 3) allow using math functions?

Thu, Feb 1, 8:56 AM
yaxunl created D42800: Let CUDA toolchain support amdgpu target.
Thu, Feb 1, 8:21 AM

Wed, Jan 31

yaxunl updated the diff for D40955: [AMDGPU] Make the new addr space mapping default.

Update tests. Removed redundant data layout.

Wed, Jan 31, 12:49 PM
yaxunl added a comment to D42711: AMDGPU: Support target triple OS component cuda.

Changing those selections make sense to me since was are adding support for a completely new and different target.

As one of the CUDA maintainers, this also makes sense to me, although we're going to need tests and (to the extent possible) wrapper functions so that it doesn't break.

There is another concern. If we need to identify IR originated from CUDA in AMDHSA OS, what should we do? Introduce CUDA again as an environment component?

There shouldn't be any reason to do this. The IR shouldn't really care what the source was.

Wed, Jan 31, 9:53 AM
yaxunl added a comment to D42711: AMDGPU: Support target triple OS component cuda.

Changing those selections make sense to me since was are adding support for a completely new and different target.

As one of the CUDA maintainers, this also makes sense to me, although we're going to need tests and (to the extent possible) wrapper functions so that it doesn't break.

Wed, Jan 31, 9:44 AM
yaxunl added a comment to D42711: AMDGPU: Support target triple OS component cuda.

I think the purpose of this patch is to get a similar usage of clang as nvptx when compiling CUDA, i.e., using cuda as OS instead of using amdhsa as OS and amdgiz as environment. This is more convenient for CUDA application developers since they just need to swap nvptx with amdgcn.

This is a frontend driver question at most. The backend shouldn't need to be aware of this

Wed, Jan 31, 8:51 AM

Tue, Jan 30

yaxunl added a comment to D42711: AMDGPU: Support target triple OS component cuda.

I think the purpose of this patch is to get a similar usage of clang as nvptx when compiling CUDA, i.e., using cuda as OS instead of using amdhsa as OS and amdgiz as environment. This is more convenient for CUDA application developers since they just need to swap nvptx with amdgcn.

Tue, Jan 30, 3:05 PM
yaxunl created D42711: AMDGPU: Support target triple OS component cuda.
Tue, Jan 30, 2:50 PM
yaxunl committed rL323826: LLParser: add an argument for overriding data layout and do not check alloca….
LLParser: add an argument for overriding data layout and do not check alloca…
Tue, Jan 30, 2:35 PM
yaxunl closed D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Tue, Jan 30, 2:35 PM
yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Tue, Jan 30, 10:43 AM
yaxunl updated the diff for D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Revised as discussed with Adrian.

Tue, Jan 30, 10:14 AM

Mon, Jan 29

yaxunl added reviewers for D41699: [OpenCL] Change sampler representation: bader, tstellar, jvesely.
Mon, Jan 29, 11:02 AM
yaxunl added a comment to D41699: [OpenCL] Change sampler representation.

@yaxunl there are two benefits of this change.

  1. As pointed by Anastasia. Currently, we have values of addressing mode flags so that they produce valid addressing mode if to combine some of them (see Anastasia's example). And the spec (https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/sampler_t.html) says addressing mode must be one of CLK_ADDRESS_REPEAT, CLK_ADDRESS_CLAMP_TO_EDGE, CLK_ADDRESS_CLAMP, CLK_ADDRESS_NONE. Though the spec doesn't require it, it's still better to diagnose if a developer specified multiple addressing modes.
  2. In current implementation filtering modes and normalized coordinates might be omitted when initializing samplers. The spec again says that these fields must be one of the predefined enums. Thus having defaults (i.e. constants of 0 values) allow a developer to omit some of the modes and write less portable code which is harder to debug.

    So these 2 points are clearly technical benefits of this patch.

Ping! @yaxunl, it would be nice to conclude how to proceed here. Do you still feel we don't have a convincing argument to go ahead with this change?

Mon, Jan 29, 10:57 AM

Fri, Jan 26

yaxunl updated the diff for D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Re-upload the patch.

Fri, Jan 26, 2:03 PM
yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

If the user does not specify target on llc command line, llc is supposed to get the target from LLVM assembly, then use it to get the datalayout string through TargetMachine. However, that means it has to parse the LLVM assembly first, but it cannot. Because to parse the LLVM assembly it needs to know the datalayout string first.

I'm probably missing something obvious here. The case where llc gets invoked without a target on the command line must be working today, doesn't it? Why can't we fall back to that code path?

This patch is trying to let llc load an llvm module which does not contain datalayout. In most cases, the parser is able to do that even though there is no datalayout in the module.

However, in some rare cases, the parser needs to know the datalayout to be able to parse the module. Therefore we discussed and concluded that we need to inject datalayout when parsing the module.

Let's consider the situation where llc command line does not contain target.

The old code path just parses the LLVM assembly and gets the target from the assembly. It can do that because it does not need to inject the datalayout.

However, now we need to inject datalayout when parsing, then we cannot since we don't know datalayout unless we parse the module to know the target first.

Fri, Jan 26, 12:45 PM
yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

If the user does not specify target on llc command line, llc is supposed to get the target from LLVM assembly, then use it to get the datalayout string through TargetMachine. However, that means it has to parse the LLVM assembly first, but it cannot. Because to parse the LLVM assembly it needs to know the datalayout string first.

I'm probably missing something obvious here. The case where llc gets invoked without a target on the command line must be working today, doesn't it? Why can't we fall back to that code path?

Fri, Jan 26, 12:10 PM
yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

You are right. My mental model of how this works was a bit out of date. We separated verification and debug info stripping recently. Let's scrap that idea.

Let's go back to your previous statement:

If target is not specified on llc command line, llc needs to parse the LLVM assembly to get the target. To parse the LLVM assembly, llc needs to pass the datalayout to LLParser first. However, it does not know the datalayout since it does not know the target.

Can you elaborate this? The problem is when only a datalayout but no target is specified on the commandline? Could you pass the datalayout as a string and have LLParser parse it?

Fri, Jan 26, 10:14 AM
yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

If target is not specified on llc command line, llc needs to parse the LLVM assembly to get the target. To parse the LLVM assembly, llc needs to pass the datalayout to LLParser first. However, it does not know the datalayout since it does not know the target.
It seems we have to go back the current approach, that is, let LLParser only checks debug info and ignores non-debug info. For those llvm tools which does not explicitly verify module after parsing, I can add explicit verification after parsing.

What about the other option: Don't run the verifier in LLParser and instead ensure that every client of LLParser runs the verifier?
We could even have the LLParser return a wrapper akin to

class UnverifiedModule {
  Module *M;
public:
  Module *verify();
}

to force clients to verify.

Fri, Jan 26, 9:40 AM
yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

I tried to add a parameter to LLParser for overriding datalayout. However I encountered another issue for llc.

Fri, Jan 26, 9:24 AM

Thu, Jan 25

yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Thanks for checking!

Based on this, we could either

  • make it the responsibility of the Caller of LLParser to run the Verifier and update those tools to run the Verifier.
  • or pass the override datalayout into LLParser so it can inject it before running the Verifier.

    I personally don't like the idea of relaxing the Verifier / making it verify something that is not what is being fed into the later stages. (Feel free to try and convince me otherwise though :-)
Thu, Jan 25, 11:44 AM
yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

LLParser already calls Verifier before that by itself

I wonder if that is actually necessary. Are there any code paths that invoke LLParser and don't run the Verifier afterwards? If not, then it would make sense to change that.

Thu, Jan 25, 11:08 AM
yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Wouldn't it be better to move the M->setDataLayout(ClDataLayout); to before we run the Verifier? It seems like we should verify the module in the state that it will be eventually consumed.

Thu, Jan 25, 10:41 AM
yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Can we reach consensus on how to fix this issue?

Thu, Jan 25, 10:37 AM
yaxunl updated the diff for D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Separate the diagnostic error message change to https://reviews.llvm.org/D42543

Thu, Jan 25, 8:41 AM
yaxunl created D42543: Change diagnostic message in verifier about incorrect alloca address space.
Thu, Jan 25, 8:37 AM
yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Thu, Jan 25, 7:49 AM

Wed, Jan 24

yaxunl updated the diff for D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Add back a change dropped by accident.

Wed, Jan 24, 2:56 PM
yaxunl updated the diff for D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Add a command line option to llvm-as to allow set datalayout. Opt already has such option but has a bug. Fixed the bug so that it works properly.
Add lit tests for llvm-as/opt.

Wed, Jan 24, 2:00 PM

Tue, Jan 23

yaxunl committed rL323216: Verifier: fix bug treating debug info issue as non-debug info issue.
Verifier: fix bug treating debug info issue as non-debug info issue
Tue, Jan 23, 8:14 AM
yaxunl closed D42391: Verifier: fix bug treating debug info issue as non-debug info issue.
Tue, Jan 23, 8:13 AM
yaxunl committed rL323214: CodeGen: Fix assertion in ScheduleDAGMILive::scheduleMI due to llvm.dbg.value.
CodeGen: Fix assertion in ScheduleDAGMILive::scheduleMI due to llvm.dbg.value
Tue, Jan 23, 8:07 AM
yaxunl closed D42394: CodeGen: Fix assertion in ScheduleDAGMILive::scheduleMI due to llvm.dbg.value.
Tue, Jan 23, 8:07 AM

Mon, Jan 22

yaxunl created D42394: CodeGen: Fix assertion in ScheduleDAGMILive::scheduleMI due to llvm.dbg.value.
Mon, Jan 22, 2:08 PM
yaxunl updated the diff for D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Separated a bug fix about verifier incorrectly treating debug info error as non-debug-info error to another review.

Mon, Jan 22, 12:06 PM
yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Mon, Jan 22, 12:02 PM
yaxunl created D42391: Verifier: fix bug treating debug info issue as non-debug info issue.
Mon, Jan 22, 11:59 AM
yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Mon, Jan 22, 11:37 AM
yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Mon, Jan 22, 10:40 AM

Jan 19 2018

yaxunl accepted D42307: [OpenCL][6.0.0 Release] Release notes for OpenCL in Clang.

LGTM. Thanks!

Jan 19 2018, 1:16 PM

Jan 16 2018

yaxunl added a comment to D40955: [AMDGPU] Make the new addr space mapping default.

Since https://reviews.llvm.org/D41832 is not trivial and may take some time, I am wondering if we should not let it block this patch.

Jan 16 2018, 2:38 PM
yaxunl updated the summary of D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Jan 16 2018, 2:33 PM
yaxunl retitled D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space from LLParser: Do not check alloca addr space if the assembly does not contain data layout definition to LLParser: do not verify LLVM module.
Jan 16 2018, 2:24 PM

Jan 15 2018

yaxunl added a comment to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

ping

Jan 15 2018, 9:24 AM
yaxunl added reviewers for D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space: rampitec, kzhuravl.
Jan 15 2018, 9:24 AM

Jan 12 2018

yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Jan 12 2018, 6:20 AM

Jan 11 2018

yaxunl updated the diff for D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Removed module verification from UpgradeDebugInfo. UpgradeDebugInfo only checks debug info.

Jan 11 2018, 12:37 PM

Jan 9 2018

yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Jan 9 2018, 8:13 AM
yaxunl added a comment to D41699: [OpenCL] Change sampler representation.

What's the benefit of this change? Since this change will require all device libraries implementing __translate_sampler_initializer to change accordingly. We need a compelling reason.

Jan 9 2018, 7:46 AM
yaxunl added a reviewer for D41699: [OpenCL] Change sampler representation: b-sumner.
Jan 9 2018, 7:42 AM

Jan 8 2018

yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Jan 8 2018, 1:35 PM
yaxunl updated the diff for D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.

Removed check of alloca addr space from LLParser.

Jan 8 2018, 12:59 PM
yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Jan 8 2018, 12:41 PM
yaxunl added inline comments to D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Jan 8 2018, 12:36 PM
yaxunl added inline comments to D40955: [AMDGPU] Make the new addr space mapping default.
Jan 8 2018, 12:27 PM
yaxunl created D41832: LLParser: add an argument for overriding data layout and do not check alloca addr space.
Jan 8 2018, 12:25 PM

Dec 20 2017

yaxunl added inline comments to D40955: [AMDGPU] Make the new addr space mapping default.
Dec 20 2017, 6:17 PM
yaxunl updated the diff for D40955: [AMDGPU] Make the new addr space mapping default.

Remove unnecessary datalayout from tests.

Dec 20 2017, 3:53 PM

Dec 14 2017

yaxunl committed rL320788: Recommit CodeGen: Fix assertion in machine inst sheduler due to llvm.dbg.value.
Recommit CodeGen: Fix assertion in machine inst sheduler due to llvm.dbg.value
Dec 14 2017, 7:57 PM
yaxunl added a comment to D40670: Let Alloca treated as nonnull for any alloca addr space value.

@nlopes Hal Finkel proposed a solution which works for me http://lists.llvm.org/pipermail/llvm-dev/2017-December/119738.html . Can you take a look if it works for you? Thanks.

Dec 14 2017, 6:32 PM
yaxunl added a comment to D40670: Let Alloca treated as nonnull for any alloca addr space value.

RFC posted http://lists.llvm.org/pipermail/llvm-dev/2017-December/119724.html

Dec 14 2017, 1:52 PM
yaxunl added a comment to D40670: Let Alloca treated as nonnull for any alloca addr space value.

How about introduce nullptr value for each addr space in data layout? E.g., assume alloca addr space is 3 and nullptr value of addr space 3 is -1. alloca of addr space 3 could return 0, but never return -1.

Then this code

if (isa<AllocaInst>(V) && Q.DL.getAllocaAddrSpace() == 0)

can be changed as

if (isa<AllocaInst>(V) && Q.DL.getAllocaNullPointerValue() == 0)

This assumes that alloca never returns nullptr value.

Nuno, Sean, will this work for you?

Thanks.

Sorry for the delay.
What if a target doesn't have an invalid pointer? This is not uncommon in embedded ISAs.

I don't particularly like the idea of mixing null pointers (which we define as having the value zero ATM), alloca not being able to return a null pointer, and the possibility of changing the value of null pointers to a non-zero value.

How about adding a hook TargetTransformInfo::isAllocaPtrValueNonZero which returns true if alloca inst value is always non-zero.

The drawback is that some ValueTracking functions will depend on TargetTransformInfo. As a result, those passes using ValueTrackign will require TargetTransformInfo.

What do you think?

Thanks.

I like that solution!

Dec 14 2017, 11:50 AM
yaxunl committed rL320712: Revert CodeGen: Fix assertion in machine inst sheduler due to llvm.dbg.value.
Revert CodeGen: Fix assertion in machine inst sheduler due to llvm.dbg.value
Dec 14 2017, 8:12 AM

Dec 13 2017

yaxunl added a comment to D40670: Let Alloca treated as nonnull for any alloca addr space value.

How about introduce nullptr value for each addr space in data layout? E.g., assume alloca addr space is 3 and nullptr value of addr space 3 is -1. alloca of addr space 3 could return 0, but never return -1.

Then this code

if (isa<AllocaInst>(V) && Q.DL.getAllocaAddrSpace() == 0)

can be changed as

if (isa<AllocaInst>(V) && Q.DL.getAllocaNullPointerValue() == 0)

This assumes that alloca never returns nullptr value.

Nuno, Sean, will this work for you?

Thanks.

Sorry for the delay.
What if a target doesn't have an invalid pointer? This is not uncommon in embedded ISAs.

I don't particularly like the idea of mixing null pointers (which we define as having the value zero ATM), alloca not being able to return a null pointer, and the possibility of changing the value of null pointers to a non-zero value.

Dec 13 2017, 2:46 PM
yaxunl committed rL320650: CodeGen: Fix assertion in machine inst sheduler due to llvm.dbg.value.
CodeGen: Fix assertion in machine inst sheduler due to llvm.dbg.value
Dec 13 2017, 2:38 PM