Page MenuHomePhabricator

uweigand (Ulrich Weigand)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 14 2013, 11:48 AM (364 w, 2 d)

Recent Activity

Fri, Apr 3

uweigand added a comment to D76624: [MSan] Add instrumentation for SystemZ.

The Z ABI implementation now looks correct to me, except for one corner case: an LLVM-level argument type of f128 is passed via implicit reference. Now, in most cases this is already handled at the clang level, i.e. when you have a "long double" at C source level, you'll already see a pointer type in the LLVM IR instead. However, there are still a few cases where there is a f128 at the LLVM IR level, e.g. as arguments to some compiler builtin / libgcc routines. Those are only transformed to implicit reference in the LLVM back-end, so I believe for completeness this case should also be handled here.

Fri, Apr 3, 11:20 AM · Restricted Project

Tue, Mar 31

uweigand committed rGc726c920e040: [SystemZ] Allow %r0 in address context for AsmParser (authored by uweigand).
[SystemZ] Allow %r0 in address context for AsmParser
Tue, Mar 31, 10:53 AM
uweigand added a comment to D71938: [SCCP] Use constant ranges for casts..

I'm now getting an assertion failure in the LNT test suite:
http://lab.llvm.org:8011/builders/clang-s390x-linux-lnt/builds/17826/steps/test-suite/logs/stdio

Tue, Mar 31, 8:16 AM · Restricted Project
uweigand accepted D76771: [SystemZ] Improve foldMemoryOperandImpl: MS(G)RKC -> MS(G)C.

LGTM, thanks!

Tue, Mar 31, 7:09 AM · Restricted Project
uweigand added inline comments to D76771: [SystemZ] Improve foldMemoryOperandImpl: MS(G)RKC -> MS(G)C.
Tue, Mar 31, 6:04 AM · Restricted Project
uweigand added a comment to D76771: [SystemZ] Improve foldMemoryOperandImpl: MS(G)RKC -> MS(G)C.

Thanks for running the benchmark, I guess I'm OK with the current implementation then.

Tue, Mar 31, 12:31 AM · Restricted Project
uweigand added a comment to D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH.

Thanks for working on this, @thakis !

Tue, Mar 31, 12:30 AM · Restricted Project, Restricted Project

Mon, Mar 30

uweigand added a comment to D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH.

Ah, good point. Dimitry, can you prepare an updated patch to implement Jonas' suggestion?

Mon, Mar 30, 6:27 AM · Restricted Project, Restricted Project
uweigand committed rG9c9d88d8b1bb: [SystemZ] Allow configuring default CLANG_SYSTEMZ_ARCH (authored by uweigand).
[SystemZ] Allow configuring default CLANG_SYSTEMZ_ARCH
Mon, Mar 30, 5:23 AM
uweigand closed D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH.
Mon, Mar 30, 5:23 AM · Restricted Project, Restricted Project

Fri, Mar 27

uweigand added a comment to D76124: [TTI] Remove getOperationCost.

Looking simply at the SystemZ test case change, for the icmp/[zs]ext case (fun1/fun2), we actually need three instructions (compare, load zero, conditional move), so the change seems reasonable.

Fri, Mar 27, 7:37 AM · Restricted Project

Thu, Mar 26

uweigand added a comment to D76771: [SystemZ] Improve foldMemoryOperandImpl: MS(G)RKC -> MS(G)C.

The more I think about it, the more it seems that the original check has always been somewhat questionable.

Thu, Mar 26, 11:55 AM · Restricted Project
uweigand added a comment to D76624: [MSan] Add instrumentation for SystemZ.

Had a look at the vararg handling. Reviewed only the ABI-relevant parts.

Thu, Mar 26, 9:11 AM · Restricted Project
uweigand committed rGdc37287320cc: [asan] Fix read_binary_name_regtest.c test dying with SIGPIPE (authored by iii).
[asan] Fix read_binary_name_regtest.c test dying with SIGPIPE
Thu, Mar 26, 5:56 AM
uweigand committed rG2ca7fe379647: [compiler-rt] Use uname syscall in GetKernelAreaSize() (authored by iii).
[compiler-rt] Use uname syscall in GetKernelAreaSize()
Thu, Mar 26, 5:56 AM
uweigand closed D76776: [compiler-rt] Use uname syscall in GetKernelAreaSize().
Thu, Mar 26, 5:55 AM · Restricted Project
uweigand closed D76576: [asan] Fix read_binary_name_regtest.c test dying with SIGPIPE.
Thu, Mar 26, 5:55 AM · Restricted Project
uweigand added a comment to D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH.

This doesn't apply cleanly to current mainline. Can you rebase and test again? I'll check it in then.

Thu, Mar 26, 5:55 AM · Restricted Project, Restricted Project
uweigand added a comment to D76771: [SystemZ] Improve foldMemoryOperandImpl: MS(G)RKC -> MS(G)C.

I'm not sure I understand those latest changes. You seem to no longer check at all whether the target opcode actually requires tied operands, you just always tie them?

Thu, Mar 26, 4:50 AM · Restricted Project

Wed, Mar 25

uweigand added inline comments to D76771: [SystemZ] Improve foldMemoryOperandImpl: MS(G)RKC -> MS(G)C.
Wed, Mar 25, 7:32 AM · Restricted Project
uweigand accepted D76055: [SystemZ] Improve foldMemoryOperandImpl()..

LGTM, thanks!

Wed, Mar 25, 7:32 AM · Restricted Project
uweigand accepted D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH.

LGTM, thanks!

Wed, Mar 25, 6:59 AM · Restricted Project, Restricted Project

Tue, Mar 24

uweigand added inline comments to D76055: [SystemZ] Improve foldMemoryOperandImpl()..
Tue, Mar 24, 9:39 AM · Restricted Project
uweigand added a comment to D76055: [SystemZ] Improve foldMemoryOperandImpl()..

See inline comments. Otherwise this looks good, but I'd rather commit this as two separate patches (the memory-immediate changes in one, and the MS(G)RKC changes in the other).

Tue, Mar 24, 9:07 AM · Restricted Project

Mon, Mar 23

uweigand added a comment to D76055: [SystemZ] Improve foldMemoryOperandImpl()..

Oops, sorry, missed your update. Will look into that shortly.

Mon, Mar 23, 9:48 AM · Restricted Project
uweigand added a comment to D76055: [SystemZ] Improve foldMemoryOperandImpl()..
logical compares (CLFHSI, CLGHSI) -- those should be trivial to add

Patch updated to include these as well, with a check for an uint<16> immediate. This gives +1800 CLGHSI and +200 CLFHSI compared to before.

Mon, Mar 23, 9:48 AM · Restricted Project
uweigand accepted D76370: [SystemZ] Perform instruction shortening for fused fp ops..

LGTM, thanks!

Mon, Mar 23, 4:20 AM · Restricted Project

Mon, Mar 16

uweigand accepted D75978: [SystemZ] Avoid scalarization of S/UINT_TO_FP.

LGTM, thanks!

Mon, Mar 16, 3:09 AM · Restricted Project
uweigand added inline comments to D76201: [TargetLowering] Only demand a rotation's modulo amount bits.
Mon, Mar 16, 2:10 AM · Restricted Project

Thu, Mar 12

uweigand added a comment to D75978: [SystemZ] Avoid scalarization of S/UINT_TO_FP.

Not yet looking at the implementation details, but a couple of comments on the overall approach:

Thu, Mar 12, 8:08 AM · Restricted Project
uweigand added a comment to D76055: [SystemZ] Improve foldMemoryOperandImpl()..

Ah, that's a good idea. I agree this makes sense.

Thu, Mar 12, 5:53 AM · Restricted Project

Tue, Mar 10

uweigand added a comment to D75914: systemz: allow configuring default CLANG_SYSTEMZ_ARCH.

Thanks for working on this! A few comments inline.

Tue, Mar 10, 6:58 AM · Restricted Project, Restricted Project

Mar 2 2020

uweigand accepted D75014: [InstrEmitter, SystemZ] Copy Access registers with the correct register class..

It seems safest to build the target instructions compared to just constrain the virtual register class of the register of the COPY.

I'm not sure I understand this: can you explain what problem you see with constraining the register class?

I remember seeing that the register allocator would create a new virtual register and give it the register class based on calling MI->getRegClassConstraint() (or TII->getRegClass() directly). So in theory, it seems that if there is no MCInstrDesc anywhere that demands a particular register class, regalloc might feel free to take the optimal one (GRX32). I am not sure this is needed, but there is no mechanism that I know of that would constrain a *COPY* register regclass, although it may be that a COPY of a physreg into a virtreg is left alone.

Maybe someone could instead confirm that physreg copies do not get their virtreg regclasses changed ever. Maybe that is obvious and I just wasn't aware. Or, if there is no guarantee for this, perhaps a target hook like I suggested (getPhysRegCopyRegClass()) would be a better solution after all, since that would also then be an error if regalloc broke that.

Mar 2 2020, 7:24 AM · Restricted Project
uweigand accepted D75290: [SystemZ] Also accept ISD::USUBO in shouldFormOverflowOp().

I see. I still agree it is preferable to only generate the overflow ops for types where they will be legal.

Mar 2 2020, 5:52 AM · Restricted Project
uweigand accepted D75367: [SystemZ] Bugfix for backchain with packed-stack.

LGTM, thanks!

Mar 2 2020, 5:52 AM · Restricted Project

Feb 28 2020

uweigand accepted D75290: [SystemZ] Also accept ISD::USUBO in shouldFormOverflowOp().

Otherwise, LGTM. Thanks!

Feb 28 2020, 4:59 AM · Restricted Project
uweigand added a comment to D75014: [InstrEmitter, SystemZ] Copy Access registers with the correct register class..

It seems safest to build the target instructions compared to just constrain the virtual register class of the register of the COPY.

Feb 28 2020, 4:59 AM · Restricted Project

Feb 25 2020

uweigand added a comment to D75014: [InstrEmitter, SystemZ] Copy Access registers with the correct register class..

Oh, and one more thing: either way, can you please add the original test case from D74601 so we're sure this problem is (and remains) fixed. Thanks!

I added the two test functions I could find already as @_ZTW1x -> tls-08.ll:@fun0, and @_Z6squareiiiiiii -> tls-09.ll.

Feb 25 2020, 8:53 AM · Restricted Project
uweigand added a comment to D74163: [demangler] Fix the parsing of long double literals for PowerPC and S390.

I'm still wondering about Intel. Can there ever be a literal encoded using 'g' on Intel? If yes, then treating it as "long double" would still be wrong, because 'g' encodes IEEE128 (__float128), while "long double" is the Intel extended (80-bit) format, right?

On the other hand, if 'g' encoded literals can never happen on Intel (or other platforms), maybe it would be better to have the code handling 'g' within a #ifdef section only active on powerpc and s390?

For X86, 'e' is used for 80-bit long double and 'g' is used for 128-bit long double. The following is the code in Clang.

clang/lib/Basic/Targets/X86.h
....
const char *getLongDoubleMangling() const override {
  return LongDoubleFormat == &llvm::APFloat::IEEEquad() ? "g" : "e";
}
...
Feb 25 2020, 7:52 AM · Restricted Project, Restricted Project
uweigand added a comment to D75014: [InstrEmitter, SystemZ] Copy Access registers with the correct register class..

I'm wondering if this handles all cases ... for CopyFromReg you apparently rely on the logic in EmitCopyFromReg that checks whether the value is used by some MachineNode with constrained regclass. But that logic isn't unconditionally used, e.g. it is skipped for "cloned" SUs ... not sure whether this could cause issues in more complicated scenarios.

Feb 25 2020, 7:38 AM · Restricted Project
uweigand added a comment to D75014: [InstrEmitter, SystemZ] Copy Access registers with the correct register class..

Oh, and one more thing: either way, can you please add the original test case from D74601 so we're sure this problem is (and remains) fixed. Thanks!

Feb 25 2020, 7:38 AM · Restricted Project
uweigand added a comment to D74163: [demangler] Fix the parsing of long double literals for PowerPC and S390.

Hi @uweigand, Thanks for your comments. Please see my explanations below.

@uweigand, Hi, I've addressed your comments. Any further comments?

I'm not very familiar with this code base. However, I am somewhat confused by your proposed change to "parseExprPrimary". In particular, where you now parse 'e' literals as "double" on powerpc/s390x, and 'g' literals as "long double" everywhere. This seems incorrect to me.

In mangled names, floating-point literals are encoded using a fixed-length lowercase hexadecimal string corresponding to the internal representation, high-order bytes first. For example, float literal -1.0f is encoded as "fbf800000". For a 64-bit long double literal on powerpc and s390x, the encoded form is type code 'e' followed by 16 hexadecimal digits. For a 128-bit long double literal on powerpc and s390x, the encoded form is type code 'g' followed by 32 hexadecimal digits. So, the proposed the change allows the parser to treat type code 'e' as a double (64-bit) and take the following 16 hexadecimal digits as the internal representation of the literal, instead of treating it as a 128-bit long double and looking for 32 hexadecimal digits after it. When the type code is 'g', the parser will be looking for 32 hexadecimal digits. These are changes for parsing literals in the mangled names.

Feb 25 2020, 3:31 AM · Restricted Project, Restricted Project

Feb 23 2020

uweigand accepted D74506: [SystemZ] Support the kernel backchain.

LGTM, thanks!

Feb 23 2020, 9:05 AM · Restricted Project, Restricted Project

Feb 22 2020

uweigand added a comment to D74163: [demangler] Fix the parsing of long double literals for PowerPC and S390.

@uweigand, Hi, I've addressed your comments. Any further comments?

Feb 22 2020, 6:06 AM · Restricted Project, Restricted Project
uweigand added inline comments to D74506: [SystemZ] Support the kernel backchain.
Feb 22 2020, 5:53 AM · Restricted Project, Restricted Project

Feb 21 2020

uweigand added a comment to D74506: [SystemZ] Support the kernel backchain.

OK, just a few more small comments, otherwise looks really good now. Thanks!

Feb 21 2020, 5:29 AM · Restricted Project, Restricted Project

Feb 20 2020

uweigand added a comment to D74506: [SystemZ] Support the kernel backchain.

Yes, this now looks correct to me. However, we now have duplicated computation between LowerFormalArguments and assignCalleeSavedSpillSlots again, which I don't really like.

Feb 20 2020, 6:22 AM · Restricted Project, Restricted Project

Feb 17 2020

uweigand added a comment to D74506: [SystemZ] Support the kernel backchain.

It seems that compiling a vararg function with gcc -mpacked-stack and -msoft-float places the stored GPRs in the default slots.

Feb 17 2020, 7:37 AM · Restricted Project, Restricted Project

Feb 13 2020

uweigand added a comment to D72685: [PowerPC] Exploit VSX rounding instrs for rint.

I believe the conversion of SNaN to QNaN is expected here. Note that the (current) C standard does not mention support signaling NaNs at all, and does not really ever mention them. This is planned to be fixed with the upcoming C2x version, which explicitly states that "rint" is supposed to implement the IEEE-754 "roundToIntegerExact" function. And that function, like most general functions defined by IEEE-754, is indeed defined to return a QNaN when the input is a SNaN.

Feb 13 2020, 2:03 AM · Restricted Project

Feb 11 2020

uweigand accepted D74352: [SystemZ] Bugfix in emitSelect().

I guess it would be nicer if we could still handle this case somehow.

Feb 11 2020, 7:32 AM · Restricted Project
uweigand added inline comments to D74352: [SystemZ] Bugfix in emitSelect().
Feb 11 2020, 4:30 AM · Restricted Project
uweigand committed rGaeba7ba9f3da: Add SystemZ release notes (authored by uweigand).
Add SystemZ release notes
Feb 11 2020, 3:54 AM

Feb 10 2020

uweigand added a comment to D72675: [Clang][Driver] Fix -ffast-math/-ffp-contract interaction.

I'm not sure whether this is deliberate (but it seems weird) or just a bug. I can ask the GCC developers ...

Please do. If there's a rationale, we should know.

Feb 10 2020, 8:34 AM · Restricted Project
uweigand accepted D74086: [SystemZ] Add a subtarget cache like some other targets already have..

It seems that the general precedence (when invoking llc) is that first (in reverse order) is "target-features", and then -mattr. So for example a function with the attribute "target-features"="-vector" compiled with llc -mattr=+vector, gets a (SystemZTargetMachine::getSubtargetImpl) FS -vector,+vector, meaning that +vector wins.

Feb 10 2020, 8:01 AM · Restricted Project

Feb 7 2020

uweigand added a comment to D74086: [SystemZ] Add a subtarget cache like some other targets already have..

We need the "+soft-float" feature in UsesVectorABI(), so we have the front end add it, so we don't need to check "-use-soft-float"="true", like the other targets, right?

Feb 7 2020, 8:36 AM · Restricted Project
uweigand accepted D73378: [SystemZ] Add implementation for the intrinsic llvm.read_register.

LGTM as well.

Feb 7 2020, 8:00 AM · Restricted Project
uweigand accepted D74146: [SytemZ] Disable vector ABI when using option -march=arch[8|9|10].
Feb 7 2020, 8:00 AM · Restricted Project, Restricted Project
uweigand added a comment to D74163: [demangler] Fix the parsing of long double literals for PowerPC and S390.
For S390, type code 'g' is used for 128-bit long double literals
Feb 7 2020, 6:03 AM · Restricted Project, Restricted Project
uweigand added a comment to D74146: [SytemZ] Disable vector ABI when using option -march=arch[8|9|10].

LGTM, thanks!

Feb 7 2020, 2:49 AM · Restricted Project, Restricted Project

Feb 4 2020

uweigand accepted D72189: [SystemZ] Support -msoft-float.

LGTM, thanks!

Feb 4 2020, 1:38 AM · Restricted Project, Restricted Project

Feb 3 2020

uweigand added a comment to D72189: [SystemZ] Support -msoft-float.

If soft-float, then we have *no* VectorABI!

Oh! I misunderstood your previous comment "with -msoft-float, GCC also falls back to the 16-byte vector alignment, so we must match that for ABI compatibility" to mean that (source code) vectors should be aligned to 16 bytes in memory.

Feb 3 2020, 6:25 AM · Restricted Project, Restricted Project

Jan 31 2020

uweigand added a comment to D72189: [SystemZ] Support -msoft-float.

Ah, I see. But note that you're now not supporting "use-soft-float" at all (which I think is fine at this step!), so you should update all tests to no longer use "use-soft-float".

Done.
All llc invocations use -mattr=soft-float instead of relying on the function attributes, as must be done.

Jan 31 2020, 5:32 AM · Restricted Project, Restricted Project

Jan 28 2020

uweigand added a comment to D72189: [SystemZ] Support -msoft-float.

174 ↗

	(On Diff #238345)

ok, removed it from this patch.

I had to change soft-float-02.ll to use -mattr=soft-float instead of a function attribute after removing this.

Jan 28 2020, 11:10 AM · Restricted Project, Restricted Project

Jan 27 2020

uweigand added inline comments to D72189: [SystemZ] Support -msoft-float.
Jan 27 2020, 5:26 AM · Restricted Project, Restricted Project

Jan 24 2020

uweigand accepted D71816: [DAGCombiner] Add combine for (not (strict_fsetcc)) to create a strict_fsetcc with the opposite condition..

LGTM.

Jan 24 2020, 6:41 AM · Restricted Project
uweigand added a comment to D72906: [X86] Improve X86 cmpps/cmppd/cmpss/cmpsd intrinsics with strictfp.

The constrained fcmp intrinsics don't allow the TRUE/FALSE predicates.

Hmm, maybe they should then? The only reason I didn't add them initially was that I wasn't sure they were useful for anything; if they are, it should be straightforward to add them back.

What would we lower it to on a target that doesn’t support it natively?

Any supported compare (quiet or signaling as appropriate, just so we get the correct exceptions), and then ignore the result (and use true/false constant result instead)?

Sure. Is that something we want to force all targets to have to implement just to handle this case for X86? Unless we can come up with a generic DAG combine to pick a valid condition alternate so that the lowering code for each target doesn't have to deal with it.

Jan 24 2020, 4:52 AM · Restricted Project

Jan 21 2020

uweigand accepted D72722: [FPEnv] [SystemZ] Platform-specific builtin constrained FP enablement.

LGTM, thanks!

Jan 21 2020, 8:51 AM · Restricted Project

Jan 20 2020

uweigand added a comment to D72675: [Clang][Driver] Fix -ffast-math/-ffp-contract interaction.

I've had a quick look at GCC, and it seems there's a couple of different issues.

Jan 20 2020, 9:49 AM · Restricted Project

Jan 17 2020

uweigand added a comment to D72906: [X86] Improve X86 cmpps/cmppd/cmpss/cmpsd intrinsics with strictfp.

The constrained fcmp intrinsics don't allow the TRUE/FALSE predicates.

Hmm, maybe they should then? The only reason I didn't add them initially was that I wasn't sure they were useful for anything; if they are, it should be straightforward to add them back.

What would we lower it to on a target that doesn’t support it natively?

Jan 17 2020, 9:35 AM · Restricted Project
uweigand added a comment to D72906: [X86] Improve X86 cmpps/cmppd/cmpss/cmpsd intrinsics with strictfp.

The constrained fcmp intrinsics don't allow the TRUE/FALSE predicates.

Jan 17 2020, 2:24 AM · Restricted Project

Jan 16 2020

uweigand added a comment to D72722: [FPEnv] [SystemZ] Platform-specific builtin constrained FP enablement.

What are the semantics of vfnmadb with respect to when it rounds vs the negation?

Jan 16 2020, 5:00 PM · Restricted Project
uweigand committed rGcebba7ce3952: [SystemZ] Avoid unnecessary conversions in vecintrin.h (authored by uweigand).
[SystemZ] Avoid unnecessary conversions in vecintrin.h
Jan 16 2020, 10:04 AM
uweigand added a comment to D72722: [FPEnv] [SystemZ] Platform-specific builtin constrained FP enablement.

A few comments (see inline) -- otherwise this looks good to me, thanks!

Jan 16 2020, 10:03 AM · Restricted Project

Jan 15 2020

uweigand added a comment to D72794: [LegalizeDAG][Mips] Add an assert to protect a uint_to_fp implementation from double rounding. Add a i32->f32 uint_to_fp implementation that avoids this code..

Why do we need to copy this algorithm here? Can't you simply add this case to TargetLowering::expandUINT_TO_FP instead?

Jan 15 2020, 11:46 AM · Restricted Project
uweigand added a comment to D72794: [LegalizeDAG][Mips] Add an assert to protect a uint_to_fp implementation from double rounding. Add a i32->f32 uint_to_fp implementation that avoids this code..

Why do we need to copy this algorithm here? Can't you simply add this case to TargetLowering::expandUINT_TO_FP instead?

Jan 15 2020, 11:46 AM · Restricted Project
uweigand added a comment to D71467: [FPEnv] Generate constrained FP comparisons from clang.

I think I have a slight preference for the second option, where there's a single method that does all the work for the two cases.

Jan 15 2020, 6:20 AM · Restricted Project, Restricted Project
uweigand committed rG870137d207f7: [FPEnv] Address post-commit review comment for D71467 (authored by uweigand).
[FPEnv] Address post-commit review comment for D71467
Jan 15 2020, 6:11 AM

Jan 14 2020

uweigand added a comment to D71467: [FPEnv] Generate constrained FP comparisons from clang.

Is this approach going to work with scope-local strictness? We need a way to do a comparison that has the non-strict properties but appears in a function that enables strictness elsewhere.

Jan 14 2020, 5:44 AM · Restricted Project, Restricted Project
uweigand committed rG6aca3e8dfa22: [FPEnv] Add some comments to IRBuilder.h (authored by uweigand).
[FPEnv] Add some comments to IRBuilder.h
Jan 14 2020, 5:26 AM
uweigand committed rG81ee484484a0: [FPEnv] Fix chain handling regression after 04a8696 (authored by uweigand).
[FPEnv] Fix chain handling regression after 04a8696
Jan 14 2020, 5:17 AM
uweigand added a comment to D72341: [FPEnv] Fix chain handling for fpexcept.strict nodes.

It turns out this patch introduced a regression with chain handling in code mixing constrained intrinsics and memory operations.

Jan 14 2020, 5:16 AM · Restricted Project

Jan 13 2020

uweigand accepted D67437: [SystemZ] Improve foldMemoryOperandImpl()..

LGTM, thanks!

Jan 13 2020, 10:44 AM · Restricted Project
uweigand committed rG04a86966fbf4: [FPEnv] Fix chain handling for fpexcept.strict nodes (authored by uweigand).
[FPEnv] Fix chain handling for fpexcept.strict nodes
Jan 13 2020, 5:39 AM
uweigand closed D72341: [FPEnv] Fix chain handling for fpexcept.strict nodes.
Jan 13 2020, 5:39 AM · Restricted Project
uweigand added a comment to D67437: [SystemZ] Improve foldMemoryOperandImpl()..

Patch updated per review (NFC). The new unused opcodes are gone, and the only superfluous mappings now added are in getMemOpcode():

LOCFHR -> LOCFH
LOCR   -> LOC

(which are not really "wrong")

Jan 13 2020, 5:01 AM · Restricted Project

Jan 12 2020

uweigand added a comment to D72341: [FPEnv] Fix chain handling for fpexcept.strict nodes.

Looks like the remaining test case changes are strictly due to scheduling.

Jan 12 2020, 9:02 AM · Restricted Project
uweigand updated the diff for D72341: [FPEnv] Fix chain handling for fpexcept.strict nodes.

Address review comments and rebase.

Jan 12 2020, 8:58 AM · Restricted Project

Jan 10 2020

uweigand updated the diff for D72341: [FPEnv] Fix chain handling for fpexcept.strict nodes.

Updated patch now that D72224 has landed. At this point, there are no test suite failures remaining.

Jan 10 2020, 11:36 AM · Restricted Project
uweigand added a comment to D67437: [SystemZ] Improve foldMemoryOperandImpl()..

Patch extended to also fold reloads into conditional load operands (both LOCR and SELR).

Jan 10 2020, 9:33 AM · Restricted Project
uweigand accepted D72224: [LegalizeVectorOps] Improve handling of multi-result operations..

OK, this looks all good to me now. I agree that there can be future API cleanup, but that can be done in follow-on patches. I think we should go with this for now.

Jan 10 2020, 6:58 AM · Restricted Project
uweigand committed rGf0fd11df7d54: [FPEnv] Invert sense of MIFlag::FPExcept flag (authored by uweigand).
[FPEnv] Invert sense of MIFlag::FPExcept flag
Jan 10 2020, 6:37 AM
uweigand closed D72466: [FPEnv][RFC] Invert sense of MIFlag::FPExcept flag.
Jan 10 2020, 6:36 AM · Restricted Project
uweigand added inline comments to D72466: [FPEnv][RFC] Invert sense of MIFlag::FPExcept flag.
Jan 10 2020, 6:36 AM · Restricted Project
uweigand committed rG76e9c2a9870e: [FPEnv] Generate constrained FP comparisons from clang (authored by uweigand).
[FPEnv] Generate constrained FP comparisons from clang
Jan 10 2020, 5:37 AM
uweigand closed D71467: [FPEnv] Generate constrained FP comparisons from clang.
Jan 10 2020, 5:37 AM · Restricted Project, Restricted Project

Jan 9 2020

uweigand created D72466: [FPEnv][RFC] Invert sense of MIFlag::FPExcept flag.
Jan 9 2020, 10:33 AM · Restricted Project
uweigand committed rGb51fa8670f3d: [SystemZ] Fix matching another pattern for nxgrk (PR44496) (authored by uweigand).
[SystemZ] Fix matching another pattern for nxgrk (PR44496)
Jan 9 2020, 10:14 AM

Jan 8 2020

uweigand added a comment to D71467: [FPEnv] Generate constrained FP comparisons from clang.

Ping again.

Jan 8 2020, 8:28 AM · Restricted Project, Restricted Project
uweigand added a comment to D72224: [LegalizeVectorOps] Improve handling of multi-result operations..

In general this all makes sense to me. See a few minor inline comments.

Jan 8 2020, 7:40 AM · Restricted Project
uweigand updated the diff for D72341: [FPEnv] Fix chain handling for fpexcept.strict nodes.

Use SmallVector::append instead of ::insert.

Jan 8 2020, 6:07 AM · Restricted Project