Page MenuHomePhabricator

uweigand (Ulrich Weigand)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 14 2013, 11:48 AM (352 w, 5 d)

Recent Activity

Yesterday

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?

Fri, Jan 17, 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.

Fri, Jan 17, 2:24 AM · Restricted Project

Thu, Jan 16

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?

Thu, Jan 16, 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
Thu, Jan 16, 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!

Thu, Jan 16, 10:03 AM · Restricted Project

Wed, Jan 15

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?

Wed, Jan 15, 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?

Wed, Jan 15, 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.

Wed, Jan 15, 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
Wed, Jan 15, 6:11 AM

Tue, Jan 14

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.

Tue, Jan 14, 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
Tue, Jan 14, 5:26 AM
uweigand committed rG81ee484484a0: [FPEnv] Fix chain handling regression after 04a8696 (authored by uweigand).
[FPEnv] Fix chain handling regression after 04a8696
Tue, Jan 14, 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.

Tue, Jan 14, 5:16 AM · Restricted Project

Mon, Jan 13

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

LGTM, thanks!

Mon, Jan 13, 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
Mon, Jan 13, 5:39 AM
uweigand closed D72341: [FPEnv] Fix chain handling for fpexcept.strict nodes.
Mon, Jan 13, 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")

Mon, Jan 13, 5:01 AM · Restricted Project

Sun, Jan 12

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.

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

Address review comments and rebase.

Sun, Jan 12, 8:58 AM · Restricted Project

Fri, Jan 10

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.

Fri, Jan 10, 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).

Fri, Jan 10, 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.

Fri, Jan 10, 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
Fri, Jan 10, 6:37 AM
uweigand closed D72466: [FPEnv][RFC] Invert sense of MIFlag::FPExcept flag.
Fri, Jan 10, 6:36 AM · Restricted Project
uweigand added inline comments to D72466: [FPEnv][RFC] Invert sense of MIFlag::FPExcept flag.
Fri, Jan 10, 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
Fri, Jan 10, 5:37 AM
uweigand closed D71467: [FPEnv] Generate constrained FP comparisons from clang.
Fri, Jan 10, 5:37 AM · Restricted Project, Restricted Project

Thu, Jan 9

uweigand created D72466: [FPEnv][RFC] Invert sense of MIFlag::FPExcept flag.
Thu, Jan 9, 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)
Thu, Jan 9, 10:14 AM

Wed, Jan 8

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

Ping again.

Wed, Jan 8, 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.

Wed, Jan 8, 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.

Wed, Jan 8, 6:07 AM · Restricted Project
uweigand added a comment to D72341: [FPEnv] Fix chain handling for fpexcept.strict nodes.

Looks like D72224 fixes those failures and removes at least one of the diffs in this patch.

Wed, Jan 8, 6:07 AM · Restricted Project

Tue, Jan 7

uweigand added a comment to D70913: [FPEnv][SelectionDAG] Relax chain requirements.

I guess you're right -- the current behavior seems correct only for fpexcept.maytrap but not fpexcept.strict nodes. The latter need to be part of both getRoot and getControlRoot. I'm not sure whether simply adding the nodes to both PendingLoads and PendingExports will work though, since then we might get duplicate chain links ... we may need a seperate list for the FP nodes. I'll have a look.

Tue, Jan 7, 8:58 AM · Restricted Project
uweigand created D72341: [FPEnv] Fix chain handling for fpexcept.strict nodes.
Tue, Jan 7, 8:58 AM · Restricted Project
uweigand committed rG14cd4a5b3247: [SystemZ] Extend fp-strict-alias test case (authored by uweigand).
[SystemZ] Extend fp-strict-alias test case
Tue, Jan 7, 3:51 AM
uweigand committed rG4814b68b7ad2: [SystemZ] Fix python failure in test case (authored by uweigand).
[SystemZ] Fix python failure in test case
Tue, Jan 7, 1:32 AM

Mon, Jan 6

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

Just a couple of general comments for now, not yet going into implementation details.

Mon, Jan 6, 6:08 AM · Restricted Project

Fri, Jan 3

uweigand added a comment to D70913: [FPEnv][SelectionDAG] Relax chain requirements.

I think this doesn't work if a constrained intrinsic is created that doesn't have have any uses, but needs to trigger an exception. The chain output ends up in PendingLoads, but PendingLoads isn't flushed if there's no stores or other operations that need to be ordered. So the basic block ends without connecting the chain from the constrained intrinsic to anything. This makes the node subject to deletion.

Fri, Jan 3, 6:56 AM · Restricted Project

Thu, Jan 2

uweigand accepted D71854: [SystemZ] Use FNeg in s390x clang builtins.

LGTM, thanks!

Thu, Jan 2, 8:42 AM · Restricted Project
uweigand committed rG63336795f0d5: [FPEnv] Default NoFPExcept SDNodeFlag to false (authored by uweigand).
[FPEnv] Default NoFPExcept SDNodeFlag to false
Thu, Jan 2, 8:05 AM
uweigand closed D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.
Thu, Jan 2, 8:05 AM · Restricted Project

Mon, Dec 30

uweigand updated the diff for D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.

Check all matched nodes whether they may raise FP exceptions.

Mon, Dec 30, 11:30 AM · Restricted Project
uweigand added inline comments to D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.
Mon, Dec 30, 11:30 AM · Restricted Project

Wed, Dec 25

uweigand updated the diff for D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.

Updated to current mainline.

Wed, Dec 25, 11:44 AM · Restricted Project
uweigand accepted D71865: [X86FixupSetCC] Remember the preceding eflags defining instruction while we're scanning the basic block instead of looking back for it..

Otherwise, this LGTM.

Wed, Dec 25, 4:27 AM · Restricted Project

Tue, Dec 24

uweigand added a comment to D71854: [SystemZ] Use FNeg in s390x clang builtins.

Otherwise this LGTM. Thanks for taking care of those!

Tue, Dec 24, 6:41 AM · Restricted Project
uweigand requested changes to D71854: [SystemZ] Use FNeg in s390x clang builtins.

This also needs updating the test cases that are testing for the old behavior:

Tue, Dec 24, 6:32 AM · Restricted Project
uweigand added a comment to D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.

I've had a closer look at the vec-strict-fptoint-256.ll changes I mention here:

In one case this led to codegen changes (different register allocation) since some copy propagation is no longer run on instructions marked as fpexcept.
Tue, Dec 24, 5:19 AM · Restricted Project

Mon, Dec 23

uweigand added inline comments to D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.
Mon, Dec 23, 1:37 PM · Restricted Project
uweigand added a comment to D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.

Another thing I forgot to mention: I've had to add a bit of code to the X86 target to set NoFPExcept flags. This is because you're using the same opcodes for both strict and non-strict compares, and adding the NoFPExcept in the non-strict avoids some codegen regressions we'd otherwise see.

Mon, Dec 23, 12:23 PM · Restricted Project
uweigand committed rG0d3f782e413c: [FPEnv][X86] More strict int <-> FP conversion fixes (authored by uweigand).
[FPEnv][X86] More strict int <-> FP conversion fixes
Mon, Dec 23, 12:18 PM
uweigand closed D71840: [FPEnv][X86] More strict int <-> FP conversion fixes.
Mon, Dec 23, 12:18 PM · Restricted Project
uweigand added inline comments to D71840: [FPEnv][X86] More strict int <-> FP conversion fixes.
Mon, Dec 23, 11:05 AM · Restricted Project
uweigand updated the diff for D71840: [FPEnv][X86] More strict int <-> FP conversion fixes.
Mon, Dec 23, 10:59 AM · Restricted Project
uweigand added inline comments to D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.
Mon, Dec 23, 10:59 AM · Restricted Project
uweigand updated the diff for D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.
Mon, Dec 23, 10:59 AM · Restricted Project
uweigand added a comment to D71742: Added intrinsics for access to FP environment.
In D71742#1794901, @kpn wrote:
In D71742#1793243, @kpn wrote:

I don't see the need. Changing the FP environment in a mixed environment program is the responsibility of the programmer, and standard calls already exist for this.

This is about inlining. In the code like this:

double f1(double x, double y) {
  return x + y;
}
double f2(double x, double y) {
  #pragma STDC FENV_ACCESS ON
  ...
  return f1(x, y);
}

compiler might inline call to f1 in f2. However the inlined function f1 expects default FP environment but is called in some other one.

Nothing here changes my statement. The compiler does _not_ change the FP environment because of the #pragma. So f1() here would behave the same whether it was inlined or not.

When f1 is defined, no pragma is in act, so its body is executed in default FP environment. f2 contains #pragma, so FP environment in its body may differ from the default. When f1 is inlined into f2, the body of f1 becomes a part of the body of f2. Basic blocks of f1 would be executed in the environment, set in f2. To keep semantics of f1 we must execute its BBs in the default environment.

I don’t see how inlining is any different than f2 calling f1 without it being inlined. f1 would execute with the f2 environment in that case too.

Mon, Dec 23, 9:06 AM · Restricted Project
uweigand added a child revision for D71840: [FPEnv][X86] More strict int <-> FP conversion fixes: D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.
Mon, Dec 23, 6:49 AM · Restricted Project
uweigand added a comment to D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.

Note that this patch has D71840 as prerequisite.

Mon, Dec 23, 6:49 AM · Restricted Project
uweigand added a parent revision for D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false: D71840: [FPEnv][X86] More strict int <-> FP conversion fixes.
Mon, Dec 23, 6:49 AM · Restricted Project
uweigand created D71841: [FPEnv] Default NoFPExcept SDNodeFlag to false.
Mon, Dec 23, 6:49 AM · Restricted Project
uweigand created D71840: [FPEnv][X86] More strict int <-> FP conversion fixes.
Mon, Dec 23, 6:30 AM · Restricted Project

Sun, Dec 22

uweigand added a comment to D69798: Implement inlining of strictfp functions.
In D69798#1793237, @kpn wrote:

If FENV_ACCESS is ON and a function is called that expects it to be OFF then isn't that just plain undefined behavior? Unless it was changed since C99 I don't see how this is the compiler's problem to solve. And the compiler really shouldn't be changing the FP environment implicitly just because an arbitrary function was called, or we fell out of an FENV_ACCESS=ON scope, or whatever.

Sun, Dec 22, 2:08 AM · Restricted Project
uweigand added a comment to D71627: [Clang FE, SystemZ] Recognize -mrecord-mcount CL option..

Fixed by 0792ef72564071f21b727d0de3a14d565950290f. My Linux powerpc64le build is good now.

make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- CC=~/llvm/Release/bin/clang LD=~/llvm/Release/bin/ld.lld O=out/powerpc64le powernv_defconfig zImage.epapr -j 30

Sun, Dec 22, 1:40 AM

Fri, Dec 20

uweigand added a comment to D71627: [Clang FE, SystemZ] Recognize -mrecord-mcount CL option..

Can we simply move all the validity checks (arg only valid on SystemZ, or arg only valid in combination with another arg) into ParseCodeGenArgs in CompilerInvocation.cpp, where the args are initially looked at?

Fri, Dec 20, 4:29 PM
uweigand accepted D68870: [SystemZ] Add a mapping from "select register" to "load on condition" (2-addr)..

LGTM, thanks!

Fri, Dec 20, 7:18 AM · Restricted Project
uweigand accepted D66868: [SystemZ] Fix handling of CC values.

LGTM, thanks!

Fri, Dec 20, 7:18 AM · Restricted Project
uweigand committed rGede8293d7d9d: [SystemZ][FPEnv] Enable strict vector FP extends/truncations (authored by uweigand).
[SystemZ][FPEnv] Enable strict vector FP extends/truncations
Fri, Dec 20, 6:38 AM

Dec 18 2019

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

Ping?

Dec 18 2019, 3:36 PM · Restricted Project, Restricted Project
uweigand accepted D71627: [Clang FE, SystemZ] Recognize -mrecord-mcount CL option..

LGTM.

Dec 18 2019, 2:19 PM
uweigand accepted D71629: [SystemZ] Recognize mrecord-mcount in backend.

LGTM with minor tweak. Thanks!

Dec 18 2019, 2:19 PM · Restricted Project
uweigand committed rG194646134408: [FPEnv] Strict versions of llvm.minimum/llvm.maximum (authored by uweigand).
[FPEnv] Strict versions of llvm.minimum/llvm.maximum
Dec 18 2019, 12:44 PM
uweigand closed D71624: [FPEnv] Strict versions of llvm.minimum/llvm.maximum.
Dec 18 2019, 12:44 PM · Restricted Project
uweigand accepted D71669: [Clang FE, SystemZ] Don't add "true" value for the "mnop-mcount" attribute..

LGTM.

Dec 18 2019, 10:56 AM · Restricted Project
uweigand added a comment to D71629: [SystemZ] Recognize mrecord-mcount in backend.

Minor cosmetic comment, otherwise this LGTM.

Dec 18 2019, 10:56 AM · Restricted Project
uweigand added a comment to D71629: [SystemZ] Recognize mrecord-mcount in backend.

Patch updated per review.

Beginning to understand how this is supposed to work now, but still not sure why the text assembly looks ok, while I see with objdump --filetype=obj the new section filled with zeros:

llc llvm/test/CodeGen/SystemZ/mrecord-mcount-01.ll -mtriple=s390x-linux-gnu -mcpu=z10 -o out.o --filetype=obj; objdump -D -z out.o

0000000000000000 <__mcount_loc>:
0:   00 00 00 00             .long   0x00000000
4:   00 00 00 00             .long   0x00000000
8:   00 00 00 00             .long   0x00000000
c:   00 00 00 00             .long   0x00000000

I was expecting to see something like <test1> and <test2> somwhere there... Will the linker fix this somehow (not sure how it could since it's just zeroes...)?

Dec 18 2019, 10:47 AM · Restricted Project

Dec 17 2019

uweigand added inline comments to D71629: [SystemZ] Recognize mrecord-mcount in backend.
Dec 17 2019, 11:49 PM · Restricted Project
uweigand added inline comments to D71629: [SystemZ] Recognize mrecord-mcount in backend.
Dec 17 2019, 11:40 PM · Restricted Project
uweigand added a comment to D67507: Refer to IEEE 754-2019 in langref instead of 2018 draft.

Should the changes to llvm.minimum / llvm.maximum be applied now?

Dec 17 2019, 11:40 PM · Restricted Project
uweigand added inline comments to D71624: [FPEnv] Strict versions of llvm.minimum/llvm.maximum.
Dec 17 2019, 11:21 PM · Restricted Project
uweigand added a comment to D71629: [SystemZ] Recognize mrecord-mcount in backend.

This is done using just raw text like gcc does it (see gcc@06477d3). Is this acceptable?

Dec 17 2019, 2:26 PM · Restricted Project
uweigand created D71624: [FPEnv] Strict versions of llvm.minimum/llvm.maximum.
Dec 17 2019, 1:08 PM · Restricted Project
uweigand committed rG1e89188d3537: [FPEnv] Remove unnecessary rounding mode argument for constrained intrinsics (authored by uweigand).
[FPEnv] Remove unnecessary rounding mode argument for constrained intrinsics
Dec 17 2019, 12:13 PM
uweigand closed D71218: [FPEnv] Remove unnecessary rounding mode argument for constrained intrinsics.
Dec 17 2019, 12:12 PM · Restricted Project, Restricted Project
uweigand added a comment to D69077: [gicombiner] Add the MatchDag structure and parse instruction DAG's from the input.

The new test case causes build bot failures (hidden by another failure that was already present):
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/28934/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Aparse-match-pattern.td

Dec 17 2019, 11:40 AM · Restricted Project
uweigand accepted D71441: [Clang FE, SystemZ] Recognize -mpacked-stack CL option.

OK, thanks!

Dec 17 2019, 11:15 AM
uweigand added a comment to D71218: [FPEnv] Remove unnecessary rounding mode argument for constrained intrinsics.

Ping

Dec 17 2019, 9:35 AM · Restricted Project, Restricted Project
uweigand committed rGd1c0f14be8a7: [SystemZ][FPEnv] Back-end support for STRICT_[SU]INT_TO_FP (authored by uweigand).
[SystemZ][FPEnv] Back-end support for STRICT_[SU]INT_TO_FP
Dec 17 2019, 9:26 AM
uweigand added a comment to D71408: [lit] Remove lit's REQUIRES-ANY directive.

It looks like this caused build bot failures:
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/28928/steps/ninja%20check%201/logs/FAIL%3A%20lit%3A%3A%20shtest-format.py

Dec 17 2019, 7:49 AM · Restricted Project, Restricted Project, Restricted Project
uweigand added a comment to D71560: [SystemZ] Improve handling of "packed-stack" function attribute..

It seems that the "backchain" attribute does not have to be checked this way, since it is simply present or non-present. Would this be preferrable perhaps also for "packed-stack" (instead of this patch)?

Dec 17 2019, 2:41 AM · Restricted Project
uweigand added a comment to D69275: Add constrained int->FP intrinsics.

General question for you and @uweigand that I realized today. Do we need to set the FPExcept bit in the flags for new nodes when we expand/promote operations?

Dec 17 2019, 2:04 AM · Restricted Project

Dec 16 2019

uweigand accepted D71441: [Clang FE, SystemZ] Recognize -mpacked-stack CL option.

OK, then I think this patch LGTM.

Dec 16 2019, 10:53 AM
uweigand added a comment to D71467: [FPEnv] Generate constrained FP comparisons from clang.

__builtin_fpclassify/isfinite/isinf/isinf_sign/isnan/isnormal/signbit are all implemented the same as the OTHER ones, except there is a strange fixup step in SEMA that removes the float->double cast. It is IMO the wrong way to do it.

I don't think it would modify the IR at all or the AST, but I'm also working on removing that hack (which is what I meant by the fp-classification type ones).

I hope the work I've done already is sufficient to unblock this patch.

Dec 16 2019, 10:07 AM · Restricted Project, Restricted Project
uweigand added a comment to D71467: [FPEnv] Generate constrained FP comparisons from clang.

I did the compare operators that didn't work right, and will do a separate patch for the fp-classification type ones: f02d6dd6c7afc08f871a623c0411f2d77ed6acf8

Dec 16 2019, 9:48 AM · Restricted Project, Restricted Project
uweigand updated the diff for D71467: [FPEnv] Generate constrained FP comparisons from clang.

Added float (f32) test cases.

Dec 16 2019, 9:39 AM · Restricted Project, Restricted Project
uweigand committed rG9f99aba1cfeb: [clang][SystemZ] Add support for -march=native (authored by uweigand).
[clang][SystemZ] Add support for -march=native
Dec 16 2019, 7:20 AM
uweigand added a comment to D71441: [Clang FE, SystemZ] Recognize -mpacked-stack CL option.

The diag::err_opt_not_valid_on_target message is emitted from CodeGenFunction::StartFunction -- does that mean if you use -mpacked-stack on a non-SystemZ target when compiling a file with many functions, you get this error message many times? If so, this should probably be moved somewhere else. (It looks like the existing check for -mnop-mcount may already have the same problem.

Dec 16 2019, 4:46 AM
uweigand accepted D71494: [SystemZ] Improve verification of MachineOperands..

LGTM, thanks!

Dec 16 2019, 4:19 AM · Restricted Project

Dec 13 2019

uweigand created D71467: [FPEnv] Generate constrained FP comparisons from clang.
Dec 13 2019, 7:11 AM · Restricted Project, Restricted Project