Page MenuHomePhabricator

uweigand (Ulrich Weigand)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 14 2013, 11:48 AM (335 w, 4 d)

Recent Activity

Fri, Sep 13

uweigand accepted D67432: [SystemZ] Merge SystemZExpandPseudo pass into SystemZPostRewrite..

This LGTM now, thanks!

Fri, Sep 13, 6:02 PM
uweigand added a comment to D67432: [SystemZ] Merge SystemZExpandPseudo pass into SystemZPostRewrite..

Since the copying into dest in selectSELRMux() serves both the purpose of increasing the number of selr/selfhr instructions as well as to prepare for expandCondMove(), it seems like the best place to have it to me. I first thought that the commutation should be moved to only be done if needed before calling expandCondMove(). However, I then one case appeared on SPEC 2006 where the commutation had made two SELRs look the same and therefore the CFG optimizer could transform the function to just have one SELR. So I am thinking that it probably is slightly preferred to "canonicalize" the SELRs and increase the chances of them becoming identical. This means I am not sure how this function could actually be simplified...

Fri, Sep 13, 4:44 AM

Thu, Sep 12

uweigand added a comment to D67432: [SystemZ] Merge SystemZExpandPseudo pass into SystemZPostRewrite..

I agree with making isHighReg a static function in SystemZRegisterInfo. I don't see why there would be any issue with a static member function, as long as it has no persistent state. The only issue with multi-threaded programs would be persistant state, e.g. a static member variable or a static variable within the member function. Arguments and (nonstatic) local variables are fine.

Thu, Sep 12, 6:12 AM

Wed, Sep 11

uweigand added a comment to D67360: [FPEnv] Document that constrained FP intrinsics cannot be mixed with non-constrained.

My understanding was that this is a temporary restriction; in the end, the goal is to allow mixing constrained an non-constrained operations, once we have the necessary barriers. Did I misunderstand this?

Wed, Sep 11, 4:26 PM · Restricted Project
uweigand added a comment to D67437: [SystemZ] Swap compare operands in foldMemoryOperandImpl() if possible..

I interpret this to mean that this patch handles some additional ~1000 cases. This seems to mean that the compare is now folded with the load load instead of with the jump, like 'lg; cgrje' => 'cg; je'. I am not sure this is really better, then? Would it be worth the trouble of adding some kind of live-in lists check before regalloc for non-allocatable phys reg(s)?

Wed, Sep 11, 4:08 PM
uweigand added a comment to D67432: [SystemZ] Merge SystemZExpandPseudo pass into SystemZPostRewrite..

I thought it was a bit simpler and cleaner to keep the expandLOCRPseudo() and expandSELRPseudo() in SystemZInstrInfo. Is it ok to use "public:" and "private:" like this, or should they be moved instead?

Wed, Sep 11, 3:38 PM

Mon, Sep 9

uweigand added inline comments to D67105: [TargetLowering] Fix another potential FPE in expandFP_TO_UINT.
Mon, Sep 9, 5:55 AM · Restricted Project
uweigand updated the diff for D67105: [TargetLowering] Fix another potential FPE in expandFP_TO_UINT.

Fixed comment typo.

Mon, Sep 9, 5:54 AM · Restricted Project

Sun, Sep 8

uweigand added a comment to D67105: [TargetLowering] Fix another potential FPE in expandFP_TO_UINT.
In D67105#1661418, @kpn wrote:

Well, I like it. The problem is solved, the pseudocode is I find a little easier to read, and the System/Z instruction sequence looks like a sideways move performance-wise.

Sun, Sep 8, 7:09 AM · Restricted Project

Fri, Sep 6

uweigand accepted D67271: [Alignment] fix dubious min function alignment.

LGTM.

Fri, Sep 6, 6:17 AM · Restricted Project

Thu, Sep 5

uweigand accepted D67151: [SystemZ] Recognize INLINEASM_BR in backend.

Anyway, given that it's already been this way, this patch LGTM. We can have a look at the indirect branch vs. scheduling question later.

Thu, Sep 5, 2:59 AM

Wed, Sep 4

uweigand added a comment to D67105: [TargetLowering] Fix another potential FPE in expandFP_TO_UINT.

So this removes the attempted handling of constant arguments. I agree with @efriedma that it doesn't make sense to just do this small optimization; we should really constant fold.

Wed, Sep 4, 10:17 AM · Restricted Project
uweigand updated the diff for D67105: [TargetLowering] Fix another potential FPE in expandFP_TO_UINT.

Remove attempt to handle constant arguments

Wed, Sep 4, 10:14 AM · Restricted Project
uweigand added a comment to D67105: [TargetLowering] Fix another potential FPE in expandFP_TO_UINT.

Ah, good point. Currently, constrained floating-point intrinsics are never constant-folded. In general, this would likely be wrong anyway, since we might not know the current rounding mode that applies.

Wed, Sep 4, 8:29 AM · Restricted Project
uweigand added a comment to D66868: [SystemZ] Fix handling of CC values.

With the current form of the patch, do we see any noticeable regression due to no additional compares after addition? If no, the patch would be OK; if yes, we'll probably have to add support for AL etc. first.

Wed, Sep 4, 6:15 AM
uweigand added inline comments to D67151: [SystemZ] Recognize INLINEASM_BR in backend.
Wed, Sep 4, 6:03 AM

Tue, Sep 3

uweigand created D67105: [TargetLowering] Fix another potential FPE in expandFP_TO_UINT.
Tue, Sep 3, 9:11 AM · Restricted Project
uweigand added inline comments to D66868: [SystemZ] Fix handling of CC values.
Tue, Sep 3, 4:34 AM

Mon, Sep 2

uweigand committed rGb21e24571146: [SystemZ] Support constrained fpto[su]i intrinsics (authored by uweigand).
[SystemZ] Support constrained fpto[su]i intrinsics
Mon, Sep 2, 9:51 AM
uweigand committed rL370674: [SystemZ] Support constrained fpto[su]i intrinsics.
[SystemZ] Support constrained fpto[su]i intrinsics
Mon, Sep 2, 9:48 AM

Thu, Aug 22

uweigand added a comment to D63877: Avoid infinite loop with asan interception.

Okay, I think I've found the issue for my way of building the sanitizers: I'm passing SANITIZER_CXX_ABI=libcxxabi while the default is libstdc++ for Linux. This results in the full C++ library being linked into the shared asan library (while I only have the ABI) which is "needed" for the failure to appear. @uweigand how do you build the sanitizer runtimes?

Thu, Aug 22, 7:15 AM · Restricted Project, Restricted Project

Wed, Aug 21

uweigand committed rGf7489141be5d: [Sanitizer] Disable -Wframe-larger-than on SystemZ (authored by uweigand).
[Sanitizer] Disable -Wframe-larger-than on SystemZ
Wed, Aug 21, 8:55 AM
uweigand committed rL369543: [Sanitizer] Disable -Wframe-larger-than on SystemZ.
[Sanitizer] Disable -Wframe-larger-than on SystemZ
Wed, Aug 21, 8:54 AM
uweigand closed D66021: [Sanitizer] Disable -Wframe-larger-than on SystemZ.
Wed, Aug 21, 8:54 AM · Restricted Project

Aug 9 2019

uweigand accepted D66021: [Sanitizer] Disable -Wframe-larger-than on SystemZ.

LGTM.

Aug 9 2019, 1:50 PM · Restricted Project

Aug 6 2019

uweigand added a comment to D65226: [Strict FP] Allow custom operation actions.

Thanks, Hal. I agree we'll need to clean up the "fallback" Expand logic once targets have moved to actually supporting strict FP nodes.

Aug 6 2019, 3:52 AM · Restricted Project
uweigand committed rG7b24dd741c6c: [Strict FP] Allow custom operation actions (authored by uweigand).
[Strict FP] Allow custom operation actions
Aug 6 2019, 3:43 AM
uweigand committed rL368012: [Strict FP] Allow custom operation actions.
[Strict FP] Allow custom operation actions
Aug 6 2019, 3:42 AM
uweigand closed D65226: [Strict FP] Allow custom operation actions.
Aug 6 2019, 3:42 AM · Restricted Project

Aug 5 2019

uweigand added a comment to D65226: [Strict FP] Allow custom operation actions.

Should we move ahead with this? I believe this is still a pre-req for D63782 ...

Aug 5 2019, 10:10 AM · Restricted Project

Jul 26 2019

uweigand added inline comments to D65226: [Strict FP] Allow custom operation actions.
Jul 26 2019, 11:52 AM · Restricted Project
uweigand added inline comments to D65226: [Strict FP] Allow custom operation actions.
Jul 26 2019, 10:39 AM · Restricted Project

Jul 25 2019

uweigand added a comment to D65226: [Strict FP] Allow custom operation actions.
In D65226#1601520, @kpn wrote:

So the PowerPC code regressions will be fixed once the strict tickets make it into the tree it sounds like.

Jul 25 2019, 12:35 PM · Restricted Project
uweigand added a comment to D65226: [Strict FP] Allow custom operation actions.
In D65226#1599743, @kpn wrote:

It looks like we're unrolling some vectors where before we weren't. That seems unfortunate. Is that the reason for the generated code quality regressions?

+1. What's the reason behind the scalarization?

Those are cases where the non-strict operation actually is not legal: e.g. the X86 target sets the operation action for FADD and FSUB vector operations to Custom. The old code simply ignored that and just emitted FADD and FSUB anyway as if they were legal, and only by chance did they match an isel pattern anyway.

The target can get the old behavior back by simply handling STRICT_FADD and STRICT_FSUB directly (presumably also via Custom operations similar to ones it uses for FADD/FSUB), so this is only a "regression" for the current fallback implementation.

Ah, ok. So I think the x86 case is a little more subtle than just *not legal*. The backend checks for *some* Custom lowerings (horizontal ops), but ultimately the non-strict vector FADD/FSUB are legal on x86. The Custom lowering code just returns the original op.

Jul 25 2019, 10:04 AM · Restricted Project
uweigand added a comment to D65226: [Strict FP] Allow custom operation actions.
In D65226#1599743, @kpn wrote:

It looks like we're unrolling some vectors where before we weren't. That seems unfortunate. Is that the reason for the generated code quality regressions?

+1. What's the reason behind the scalarization?

Jul 25 2019, 4:52 AM · Restricted Project

Jul 24 2019

uweigand added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

I've now posted a patch implementing something along those lines here: https://reviews.llvm.org/D65226

Jul 24 2019, 10:27 AM · Restricted Project
uweigand created D65226: [Strict FP] Allow custom operation actions.
Jul 24 2019, 10:23 AM · Restricted Project

Jul 22 2019

uweigand committed rG9488d77b44ee: [SystemZ] Add release notes on the LLVM 9 branch (authored by uweigand).
[SystemZ] Add release notes on the LLVM 9 branch
Jul 22 2019, 7:39 AM
uweigand committed rL366693: [SystemZ] Add release notes on the LLVM 9 branch.
[SystemZ] Add release notes on the LLVM 9 branch
Jul 22 2019, 7:38 AM
uweigand committed rG03f9f945ad3e: Revert r366413 on LLVM 9 branch (authored by uweigand).
Revert r366413 on LLVM 9 branch
Jul 22 2019, 7:09 AM
uweigand committed rL366690: Revert r366413 on LLVM 9 branch.
Revert r366413 on LLVM 9 branch
Jul 22 2019, 7:09 AM
uweigand added a comment to D63877: Avoid infinite loop with asan interception.

I've now reverted the patch on the LLVM 9 branch as well (r366690).

Jul 22 2019, 7:08 AM · Restricted Project, Restricted Project

Jul 21 2019

uweigand committed rL366654: Use https as vcs_protocol for the systemz builder.
Use https as vcs_protocol for the systemz builder
Jul 21 2019, 4:48 AM

Jul 19 2019

uweigand added a comment to D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics.

I've been thinking about the getStrictFPOperationAction issue. I believe this function makes no sense at all and really should go away. Instead, the strict opcodes should use their own operation actions just like everything else. In current code, those should now be set up in a reasonable manner: they all default to Expand, unless the target overrides them (to whatever makes sense).

Jul 19 2019, 9:20 AM · Restricted Project
uweigand added a comment to D63877: Avoid infinite loop with asan interception.

Looks like this patch was reverted on mainline now.

Jul 19 2019, 7:17 AM · Restricted Project, Restricted Project

Jul 18 2019

uweigand added a comment to D63877: Avoid infinite loop with asan interception.

I tried to run it on my Intel system for comparison, and the test case is failing there too:

Jul 18 2019, 12:16 PM · Restricted Project, Restricted Project
uweigand updated subscribers of D63877: Avoid infinite loop with asan interception.

Just a quick heads-up: the new test case is failing on SystemZ. I'm not quite sure why, but the build bots show this error:

Jul 18 2019, 6:52 AM · Restricted Project, Restricted Project

Jul 16 2019

uweigand committed rG450c62e33ea5: [Strict FP] Allow more relaxed scheduling (authored by uweigand).
[Strict FP] Allow more relaxed scheduling
Jul 16 2019, 8:59 AM
uweigand committed rL366222: [Strict FP] Allow more relaxed scheduling.
[Strict FP] Allow more relaxed scheduling
Jul 16 2019, 8:59 AM
uweigand closed D64412: [Strict FP] Allow more relaxed scheduling.
Jul 16 2019, 8:59 AM · Restricted Project
uweigand added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

Just to clarify one thing: even the current implementation, before this patch, does not guarantee the relative order of FP instructions and memory instructions is unchanged. So even the current implementation may perform the reschedule your comment mentions. This patch would add the additional option of also changing the relative order of the two strict_fmul operations.

Jul 16 2019, 12:29 AM · Restricted Project

Jul 15 2019

uweigand added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

Ping? It would be good to get this in LLVM 9 ...

Jul 15 2019, 10:04 AM · Restricted Project

Jul 12 2019

uweigand accepted D64658: [SystemZ] Fix addcarry of addcarry of const carry (PR42606).

I agree it's a bit hacky, but I don't see any better solution either. In any case, the change is not wrong -- everything rejected should be rejected. Given that this fixes a real problem, I'm fine with the patch. LGTM.

Jul 12 2019, 12:27 PM · Restricted Project
uweigand committed rG38ec89a670a2: [SystemZ] Fix build bot failure after r365932 (authored by uweigand).
[SystemZ] Fix build bot failure after r365932
Jul 12 2019, 11:47 AM
uweigand committed rL365942: [SystemZ] Fix build bot failure after r365932.
[SystemZ] Fix build bot failure after r365932
Jul 12 2019, 11:45 AM
uweigand committed rGb98bf60ef7a7: [SystemZ] Add support for new cpu architecture - arch13 (authored by uweigand).
[SystemZ] Add support for new cpu architecture - arch13
Jul 12 2019, 11:19 AM
uweigand committed rL365933: [SystemZ] Add support for new cpu architecture - arch13.
[SystemZ] Add support for new cpu architecture - arch13
Jul 12 2019, 11:15 AM
uweigand committed rG0f0a8b77843e: [SystemZ] Add support for new cpu architecture - arch13 (authored by uweigand).
[SystemZ] Add support for new cpu architecture - arch13
Jul 12 2019, 11:15 AM
uweigand committed rL365932: [SystemZ] Add support for new cpu architecture - arch13.
[SystemZ] Add support for new cpu architecture - arch13
Jul 12 2019, 11:14 AM
uweigand added a comment to D60716: [DwarfDebug] Dump call site debug info into DWARF.

Thanks for the quick revert! The new patch looks reasonable to me.

Jul 12 2019, 5:42 AM · Restricted Project, debug-info

Jul 11 2019

uweigand added a comment to D60716: [DwarfDebug] Dump call site debug info into DWARF.

This commit broke codegen on SystemZ, we're now failing both the test-suite and the multistage bootstrap. Unfortunately this wasn't detected earlier since the SystemZ build bot was down.

Jul 11 2019, 11:03 AM · Restricted Project, debug-info

Jul 9 2019

uweigand added a comment to D64412: [Strict FP] Allow more relaxed scheduling.

This scheduler generally only operates on single basic blocks, so it would not move anything outside of a test.

Jul 9 2019, 8:20 AM · Restricted Project
uweigand created D64412: [Strict FP] Allow more relaxed scheduling.
Jul 9 2019, 6:18 AM · Restricted Project

Jul 5 2019

uweigand accepted D64213: [SystemZ] Fix addcarry of usubo (PR42512).

LGTM, thanks!

Jul 5 2019, 12:57 PM · Restricted Project
uweigand requested changes to D64213: [SystemZ] Fix addcarry of usubo (PR42512).
Jul 5 2019, 10:06 AM · Restricted Project
uweigand added a comment to D64213: [SystemZ] Fix addcarry of usubo (PR42512).

Unfortunately, I think this gets the semantics wrong, because "carry" and "borrow" use *different* CC values on SystemZ.

Jul 5 2019, 10:06 AM · Restricted Project

Jun 28 2019

uweigand added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

Thank you. I think I got what you said. Dynamic rounding mode can be applied to static rounding mode so long as the environment rounding mode is correct set by other user/system code before. So to avoid the UB, initial work of environment(clear exception and set rounding mode to nearest) can be done at the beginning of program, maybe in runtime library.

Jun 28 2019, 6:18 AM · Restricted Project

Jun 27 2019

uweigand added a comment to D54649: [FPEnv] Rough out constrained FCmp intrinsics.
Jun 27 2019, 12:45 PM · Restricted Project
uweigand added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

I have another question about any_*.

For example, I see you use any_fadd to match both fadd and strict_fadd. I guess ZSystem target is similar to POWER that there is no fp addition machine instruction with nearest rounding mode and no exception statically.
But the semantic of fadd node requires. So theoretically, fadd node should be mapped into 2 instructions for correct compiling. One sets rounding mode to nearest and clear exception handler bit(no exception happens), the other is float addition.
Do we not handle fadd like above because there is no function error for such fine-grained instruction semantic mostly? And avoid performance penalty? @uweigand

Jun 27 2019, 3:58 AM · Restricted Project

Jun 26 2019

uweigand committed rG4c86dd903265: Allow matching extend-from-memory with strict FP nodes (authored by uweigand).
Allow matching extend-from-memory with strict FP nodes
Jun 26 2019, 10:20 AM
uweigand committed rL364450: Allow matching extend-from-memory with strict FP nodes.
Allow matching extend-from-memory with strict FP nodes
Jun 26 2019, 10:20 AM
uweigand added a comment to D60091: [test-suite] Signal error if llvm-lit was not found.

Uhm, that makes no sense.
How is that test runs, not via check target?

Jun 26 2019, 10:09 AM · Restricted Project
uweigand added a comment to D60091: [test-suite] Signal error if llvm-lit was not found.

This seems to have broken test-suite build bots?

Jun 26 2019, 9:46 AM · Restricted Project
uweigand added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

Is there any further step to enable the rounding-mode infra to handle rounding mode metadata in intrinsics? For example, covert rounding mode metadata to a new constant operand of strict_* series op. If some target/platform does not have related machine instruction for different static rounding-mode, then ignore this constant in td selection.

Jun 26 2019, 7:55 AM · Restricted Project

Jun 24 2019

uweigand added a comment to D62890: [DAGCombiner] Merge consecutive stores of vector elements before types are legalized.

Hi @jonpa, could you have a look if it is a real reg in SystemZ's change?

Jun 24 2019, 9:53 AM · Restricted Project

Jun 19 2019

uweigand added a comment to D63366: AMDGPU: Add GWS instruction builtins.

I'm now getting test suite failures like this:

Jun 19 2019, 8:11 AM
uweigand committed rG3641b10f3d58: [SystemZ] Support vector load/store alignment hints (authored by uweigand).
[SystemZ] Support vector load/store alignment hints
Jun 19 2019, 7:19 AM
uweigand committed rL363806: [SystemZ] Support vector load/store alignment hints.
[SystemZ] Support vector load/store alignment hints
Jun 19 2019, 7:18 AM

Jun 18 2019

uweigand committed rG45b10d2da5c9: [compiler-rt][SystemZ] Work around ASAN failures via -fno-partial-inlining (authored by uweigand).
[compiler-rt][SystemZ] Work around ASAN failures via -fno-partial-inlining
Jun 18 2019, 6:24 AM
uweigand committed rL363679: [compiler-rt][SystemZ] Work around ASAN failures via -fno-partial-inlining.
[compiler-rt][SystemZ] Work around ASAN failures via -fno-partial-inlining
Jun 18 2019, 6:24 AM

Jun 9 2019

uweigand abandoned D22011: [SystemZ] Generate fewer instructions for (sub <constant>, x).
Jun 9 2019, 5:18 PM
uweigand commandeered D22011: [SystemZ] Generate fewer instructions for (sub <constant>, x).
Jun 9 2019, 5:18 PM

Jun 7 2019

uweigand accepted D60888: [SystemZ] Favor 3-address instructions during instruction selection..

At this point, this looks good to me. Thanks!

Jun 7 2019, 1:36 PM

Jun 6 2019

uweigand added inline comments to D60888: [SystemZ] Favor 3-address instructions during instruction selection..
Jun 6 2019, 12:40 PM

Jun 5 2019

uweigand abandoned D52786: [MI] New flag mayAccessMemory.
Jun 5 2019, 3:34 PM · Restricted Project
uweigand abandoned D52785: [PseudoSourceValue] New category to represent floating-point status.
Jun 5 2019, 3:34 PM · Restricted Project
uweigand committed rG6c5d5ce5517b: Allow target to handle STRICT floating-point nodes (authored by uweigand).
Allow target to handle STRICT floating-point nodes
Jun 5 2019, 3:34 PM
uweigand committed rL362663: Allow target to handle STRICT floating-point nodes.
Allow target to handle STRICT floating-point nodes
Jun 5 2019, 3:34 PM
uweigand abandoned D45576: [RFC] Allow target to handle STRICT floating-point nodes.
Jun 5 2019, 3:34 PM
uweigand closed D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.
Jun 5 2019, 3:34 PM · Restricted Project
uweigand added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

OK. I'm convinced. This should let us get a correct solution in place, and as you say we can add on something to handle rounding modes later if needed.

You should probably address Kit's minor comments, but otherwise I'd be very happy to see this committed.

Jun 5 2019, 3:14 PM · Restricted Project
uweigand updated the diff for D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

Addressed review comments and updated to mainline changes.

Jun 5 2019, 3:14 PM · Restricted Project
uweigand added inline comments to D60888: [SystemZ] Favor 3-address instructions during instruction selection..
Jun 5 2019, 12:45 PM

Jun 4 2019

uweigand added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

Under "fpexcept.strict" we cannot eliminate the compare because it may raise an exception (though we can still get rid of the JCC), but under "fpexcept.maytrap" we can eliminate the compare because our only promise is that we won't raise spurious exceptions.

Jun 4 2019, 11:01 AM · Restricted Project
uweigand added a comment to D60888: [SystemZ] Favor 3-address instructions during instruction selection..

Looking mostly good now, thanks! Just a few remaining questions/comments inline ...

Jun 4 2019, 10:41 AM

Jun 3 2019

uweigand added a comment to D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

Why is the FPBarrierChain getting involved with the BarrierChain for memory objects? Even without this patch I think we might be entangling the strict FP nodes with other chained nodes more than we should.

Jun 3 2019, 1:17 PM · Restricted Project
uweigand added a comment to D62803: [SystemZ] Handle 3-address instructions in foldMemoryOperandImpl().

I'm a bit confused about the mapping logic. For the case of e.g. ADD, we today have

AR ---> gets mapped to A by getMemOpcode

and

ARK --> no mapping via getMemOpcode
Jun 3 2019, 12:55 PM

May 31 2019

uweigand accepted D60888: [SystemZ] Favor 3-address instructions during instruction selection..

I think this is good for now. We can work on further improving folded reloads as a follow-on. LGTM.

May 31 2019, 12:23 PM
uweigand accepted D62370: [NFC] Check the endianness after the CodeGenPrepare.

I agree this still checks the same thing, so the patch LGTM.

May 31 2019, 12:12 PM · Restricted Project

May 29 2019

uweigand added a comment to D37035: Implement __builtin_LINE() et. al. to support source location capture..

As of r361920, the SystemZ build bots are green again. Thanks, Eric!

May 29 2019, 4:26 AM · Restricted Project