Page MenuHomePhabricator

uweigand (Ulrich Weigand)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 14 2013, 11:48 AM (327 w, 16 h)

Recent Activity

Yesterday

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

Fri, Jul 19

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

Fri, Jul 19, 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.

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

Thu, Jul 18

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:

Thu, Jul 18, 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:

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

Tue, Jul 16

uweigand committed rG450c62e33ea5: [Strict FP] Allow more relaxed scheduling (authored by uweigand).
[Strict FP] Allow more relaxed scheduling
Tue, Jul 16, 8:59 AM
uweigand committed rL366222: [Strict FP] Allow more relaxed scheduling.
[Strict FP] Allow more relaxed scheduling
Tue, Jul 16, 8:59 AM
uweigand closed D64412: [Strict FP] Allow more relaxed scheduling.
Tue, Jul 16, 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.

Tue, Jul 16, 12:29 AM · Restricted Project

Mon, Jul 15

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

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

Mon, Jul 15, 10:04 AM · Restricted Project

Fri, Jul 12

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.

Fri, Jul 12, 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
Fri, Jul 12, 11:47 AM
uweigand committed rL365942: [SystemZ] Fix build bot failure after r365932.
[SystemZ] Fix build bot failure after r365932
Fri, Jul 12, 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
Fri, Jul 12, 11:19 AM
uweigand committed rL365933: [SystemZ] Add support for new cpu architecture - arch13.
[SystemZ] Add support for new cpu architecture - arch13
Fri, Jul 12, 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
Fri, Jul 12, 11:15 AM
uweigand committed rL365932: [SystemZ] Add support for new cpu architecture - arch13.
[SystemZ] Add support for new cpu architecture - arch13
Fri, Jul 12, 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.

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

Thu, Jul 11

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.

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

Tue, Jul 9

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.

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

Fri, Jul 5

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

LGTM, thanks!

Fri, Jul 5, 12:57 PM · Restricted Project
uweigand requested changes to D64213: [SystemZ] Fix addcarry of usubo (PR42512).
Fri, Jul 5, 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.

Fri, Jul 5, 10:06 AM · Restricted Project

Fri, Jun 28

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.

Fri, Jun 28, 6:18 AM · Restricted Project

Thu, Jun 27

uweigand added a comment to D54649: [FPEnv] Rough out constrained FCmp intrinsics.
Thu, Jun 27, 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

Thu, Jun 27, 3:58 AM · Restricted Project

Wed, Jun 26

uweigand committed rG4c86dd903265: Allow matching extend-from-memory with strict FP nodes (authored by uweigand).
Allow matching extend-from-memory with strict FP nodes
Wed, Jun 26, 10:20 AM
uweigand committed rL364450: Allow matching extend-from-memory with strict FP nodes.
Allow matching extend-from-memory with strict FP nodes
Wed, Jun 26, 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?

Wed, Jun 26, 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?

Wed, Jun 26, 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.

Wed, Jun 26, 7:55 AM · Restricted Project

Mon, Jun 24

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?

Mon, Jun 24, 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

May 27 2019

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

Looks like this test is failing on SystemZ since it was added, making all our build bots red:

May 27 2019, 4:57 PM · Restricted Project

May 16 2019

uweigand accepted D62036: [SystemZ] Bugfix in SystemZTargetLowering::combineIntDIVREM().

LGTM, thanks!

May 16 2019, 4:50 PM

May 13 2019

uweigand updated the diff for D55506: [RFC v2] Allow target to handle STRICT floating-point nodes.

Updated to address issues raised during the review:

May 13 2019, 4:18 AM · Restricted Project
uweigand committed rG8e42f6ddc80f: [SystemZ] Model floating-point control register (authored by uweigand).
[SystemZ] Model floating-point control register
May 13 2019, 2:46 AM
uweigand committed rL360570: [SystemZ] Model floating-point control register.
[SystemZ] Model floating-point control register
May 13 2019, 2:45 AM

Apr 29 2019

uweigand added a comment to D61049: Let llvm-cvtres (and lld-link) report duplicate resources.

I tried to fix this in r359414. Sorry for the breakage, and sorry for the slow turnaround, I was away on Friday.

Apr 29 2019, 3:21 AM · Restricted Project

Apr 26 2019

uweigand added a comment to D60888: [SystemZ] Favor 3-address instructions during instruction selection..

Sorry if I was not clear in my description, but what I meant to illustrate is that the RA allocates the VRegs in the order I listed them. So first %21 is allocated $r2d, and then the next VReg assigned is %12, and then %13, %14, ..., %20, %21.

Apr 26 2019, 2:07 PM
uweigand added a comment to D60888: [SystemZ] Favor 3-address instructions during instruction selection..

As explained previously, there is no propagation of hints from the COPY because that type of search is not performed. Not sure if I should attempt that...

Apr 26 2019, 12:38 PM
uweigand added a comment to D60888: [SystemZ] Favor 3-address instructions during instruction selection..
> %12 -> $r0d // does not see that $r2d would be better
Apr 26 2019, 11:51 AM

Apr 25 2019

uweigand added a comment to D61049: Let llvm-cvtres (and lld-link) report duplicate resources.

It looks like this new test case fails on big-endian systems, like this:
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/24725

Apr 25 2019, 11:03 AM · Restricted Project

Apr 24 2019

uweigand added inline comments to D60294: [DAGCombiner] [CodeGenPrepare] Split large offsets from base addresses.
Apr 24 2019, 12:20 PM · Restricted Project
uweigand added inline comments to D60294: [DAGCombiner] [CodeGenPrepare] Split large offsets from base addresses.
Apr 24 2019, 5:28 AM · Restricted Project

Apr 23 2019

uweigand added a comment to D60888: [SystemZ] Favor 3-address instructions during instruction selection..

This looks really promising, in particular the reduction in spills and copies. Can you check that this also addresses the problem described here: https://reviews.llvm.org/D22011 ?

I beleive so - at least the two test functions there are now improved to use lghi/lgfi + sgrk :-)

Apr 23 2019, 12:43 AM

Apr 22 2019

uweigand added a comment to D60294: [DAGCombiner] [CodeGenPrepare] Split large offsets from base addresses.

Those test case changes represent an actual improvement here, so this looks good. Thanks!

Apr 22 2019, 4:32 AM · Restricted Project

Apr 19 2019

uweigand added a comment to D60888: [SystemZ] Favor 3-address instructions during instruction selection..

This looks really promising, in particular the reduction in spills and copies. Can you check that this also addresses the problem described here: https://reviews.llvm.org/D22011 ?

Apr 19 2019, 4:41 AM

Apr 16 2019

uweigand committed rG452060ab871a: [SystemZ] Add missing intrinsics to intrinsics-immarg.ll (authored by uweigand).
[SystemZ] Add missing intrinsics to intrinsics-immarg.ll
Apr 16 2019, 7:34 AM
uweigand committed rL358495: [SystemZ] Add missing intrinsics to intrinsics-immarg.ll.
[SystemZ] Add missing intrinsics to intrinsics-immarg.ll
Apr 16 2019, 7:34 AM

Apr 15 2019

uweigand added a comment to D58923: [SystemZ] Utilize Compare/Add/Sub "High" instructions.

Not a full review yet, but a couple of comments (in the test case) where the resulting code could be simplified.

Apr 15 2019, 10:39 AM

Apr 10 2019

uweigand added a comment to D60169: Proposed refactoring for lib/Target/X86 to remove layering issue.

On SystemZ, there is no dependency from InstPrinter to MCTargetDesc (or anything else in the target) as far as I can see. That means we don't have an issue, right?

Apr 10 2019, 5:04 AM

Apr 4 2019

uweigand accepted D60255: [SystemZ] Bugfix in isFusableLoadOpStorePattern()..

LGTM, thanks!

Apr 4 2019, 4:38 AM

Apr 3 2019

uweigand added a comment to D60020: [DAGCombiner][X86][SystemZ] Canonicalize SSUBO with immediate RHS to SADDO by negating the immediate..

-Update a SystemZ test I missed cause I only had X86 building previously. I think this one of these cases is a regression, but that's probably also going to happen with the InstCombine version of this patch too. So probably needs to be fixed regardless.

Apr 3 2019, 8:10 AM · Restricted Project
uweigand committed rG35dfd1b7dfe9: [SystemZ] Improve codegen for certain SADDO-immediate cases (authored by uweigand).
[SystemZ] Improve codegen for certain SADDO-immediate cases
Apr 3 2019, 8:10 AM
uweigand committed rL357597: [SystemZ] Improve codegen for certain SADDO-immediate cases.
[SystemZ] Improve codegen for certain SADDO-immediate cases
Apr 3 2019, 8:08 AM

Mar 29 2019

uweigand added a comment to D60006: [SelectionDAG] Add fcmp UNDEF handling to SelectionDAG::FoldSetCC.

The SystemZ test case change is fine with me, thanks!

Mar 29 2019, 4:15 PM · Restricted Project

Mar 17 2019

uweigand added a comment to D59363: [SelectionDAG] Add icmp UNDEF handling to SelectionDAG::FoldSetCC.

I think the SystemZ test changes look ok (by replacing the undef operands with an argument the tests are more or less unaffected by this patch), but as usual I will let Uli do the formal approval.

Mar 17 2019, 2:31 PM · Restricted Project

Mar 4 2019

uweigand added inline comments to D58884: [DAGCombiner][X86][SystemZ][AArch64] Combine some cases of (bitcast (build_vector constants)) between legalize types and legalize dag..
Mar 4 2019, 6:09 AM · Restricted Project

Feb 27 2019

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

Well, I have a question about why is it not enough to use use/def of physical register in MI level to prevent the reordering of instructions about set/get fp status register? For example, If the instruction which setting rounding mode, and then the instruction which read the rounding mode, the sequence would not be reordered because of the dependency of rounding mode bits (fp status register).

This would be enough to handle rounding-mode aspects. But if FP exceptions are enabled, we have additional restrictions: all FP exceptions could then have additional side effects (trap) and therefore cannot be executed speculatively, even where that would be OK from a status register dataflow perspective.

Also, one goal of the design is that we do not have to duplicate all FP instruction patterns in the back-end; we want a single pattern that can handle both the strict and non-strict case. If we wanted to a phys reg def, that would then have to be optional in some form, and there's no good way I can see to do this in the current infrastructure.

OK. If we use tablegen multiclass to define two kinds of instructions is not too much work because of multiclass. One for strict fp pattern and one for normal non-strict although they will be mapped to same instruction in some targets but with different flags(one has hasSideEffect flag, one hasn't) or phys reg def/use?

Feb 27 2019, 4:45 AM

Feb 26 2019

uweigand added a comment to D58521: [DAGCombiner] allow truncation of binops after legalization if desirable.

I tried this patch on SystemZ / SPEC, and as before this seems to have a relatively very minor impact on the number of files changed (7), and on the performance (seemingly unaffected).

I think the SystemZ test looks good, but I leave the final approval to Uli as usual.

Feb 26 2019, 2:27 AM · Restricted Project
uweigand added a comment to D45576: [RFC] Allow target to handle STRICT floating-point nodes.

Well, I have a question about why is it not enough to use use/def of physical register in MI level to prevent the reordering of instructions about set/get fp status register? For example, If the instruction which setting rounding mode, and then the instruction which read the rounding mode, the sequence would not be reordered because of the dependency of rounding mode bits (fp status register).

Feb 26 2019, 2:27 AM
uweigand accepted D58270: [SystemZ] Load all vector and FP constants in Select() .

OK, this version LGTM. Thanks!

Feb 26 2019, 1:25 AM

Feb 25 2019

uweigand added a comment to D58270: [SystemZ] Load all vector and FP constants in Select() .

Yes, that seems to simplify things. I however am somewhat wary to create DAG nodes during all the queries during legalization, so I instead first make a vector of unsigned and then make the actual DAG operands in loadVectorConstant().

Feb 25 2019, 3:55 AM

Feb 21 2019

uweigand added a comment to D58270: [SystemZ] Load all vector and FP constants in Select() .

This looks generally good to me. Some additional options to possibly make the code simpler occurred to me:

Feb 21 2019, 4:10 AM
uweigand added a comment to D58490: [ARM] Be super conservative about atomics.

The SystemZ part LGTM, thanks.

Feb 21 2019, 3:35 AM · Restricted Project

Feb 20 2019

uweigand accepted D58353: SystemZ: Add ImmArg to intrinsics.

LGTM, thanks!

Feb 20 2019, 7:29 AM

Feb 19 2019

uweigand added a comment to D58353: SystemZ: Add ImmArg to intrinsics.

Thanks, this should now cover all intrinsics with immediate arguments. Some additional comments inline (mostly cosmetic, with one real fix for int_s390_vfisb).

Feb 19 2019, 3:00 AM

Feb 18 2019

uweigand added a comment to D58270: [SystemZ] Load all vector and FP constants in Select() .
Could we actually handle FP128 as well with a present FeatureVectorEnhancements1?
Feb 18 2019, 9:56 AM
uweigand added a comment to D58353: SystemZ: Add ImmArg to intrinsics.

I'm not quite sure I understand the logic why some intrinsics that require immediate arguments are marked with ImmArg, but others are not?

Shouldn't we mark all of them? The ones I see missing in your patch are:

defm int_s390_vfae  : SystemZTernaryIntCCBHF;
defm int_s390_vfaez : SystemZTernaryIntCCBHF;
defm int_s390_vstrc  : SystemZQuaternaryIntCCBHF;
defm int_s390_vstrcz : SystemZQuaternaryIntCCBHF;
def int_s390_vfmaxdb : Intrinsic<[llvm_v2f64_ty],
def int_s390_vfmindb : Intrinsic<[llvm_v2f64_ty],
def int_s390_vfmaxsb : Intrinsic<[llvm_v4f32_ty],
def int_s390_vfminsb : Intrinsic<[llvm_v4f32_ty],
def int_s390_vftcidb : SystemZBinaryConvIntCC<llvm_v2i64_ty, llvm_v2f64_ty>;
def int_s390_vftcisb : SystemZBinaryConvIntCC<llvm_v4i32_ty, llvm_v4f32_ty>;
def int_s390_vfidb : Intrinsic<[llvm_v2f64_ty],
def int_s390_vfisb : Intrinsic<[llvm_v4f32_ty],

Maybe it would actually make more sense to add the ImmArg directly in the SystemZ*Int* helper macros; those intrinsics really all need immediate arguments. (The sole exception I can see is verll, but that probably should use a different helper then.)

I'm doing this blindly based on the definitions here https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/BuiltinsSystemZ.def
Are these accurate and complete?

Feb 18 2019, 9:04 AM
uweigand added a comment to D58353: SystemZ: Add ImmArg to intrinsics.

I'm not quite sure I understand the logic why some intrinsics that require immediate arguments are marked with ImmArg, but others are not?

Feb 18 2019, 8:37 AM

Feb 14 2019

uweigand accepted D58240: [SystemZ] Make sure VEXTEND and VROUND nodes are not emitted without vector support..

Ah, good catch! LGTM.

Feb 14 2019, 9:36 AM

Feb 13 2019

uweigand added a comment to D58142: [SystemZ] Accept more constant FP BuildVectors..

Hmm. Actually, I'm now wondering why we need to reject anything in the first place. Can't we improve isFPImmLegal to accept *anything* that can be constructed via any of the vector instructions (VGBM, VGM, VREPI)?

Feb 13 2019, 5:44 AM

Feb 12 2019

uweigand accepted D58003: [SystemZ] Use VGM whenever possible to load FP immediates.

Yes, I think this version is better.

Feb 12 2019, 4:41 AM

Feb 11 2019

uweigand added a comment to D58003: [SystemZ] Use VGM whenever possible to load FP immediates.

It seems you're assuming VGM is always available. I guess there needs to be a check for hasVector() somewhere.

Feb 11 2019, 4:58 AM