Page MenuHomePhabricator

ebevhan (Bevin Hansson)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 16 2018, 6:47 AM (57 w, 1 d)

Recent Activity

Today

ebevhan added inline comments to D58346: [Sema] Change addr space diagnostics in casts to follow C++ style.
Wed, Feb 20, 6:26 AM
ebevhan added inline comments to D58346: [Sema] Change addr space diagnostics in casts to follow C++ style.
Wed, Feb 20, 5:02 AM
ebevhan added inline comments to D58236: Make address space conversions a bit stricter..
Wed, Feb 20, 1:46 AM · Restricted Project
ebevhan updated the diff for D58236: Make address space conversions a bit stricter..
Wed, Feb 20, 1:33 AM · Restricted Project

Yesterday

ebevhan added inline comments to D58346: [Sema] Change addr space diagnostics in casts to follow C++ style.
Tue, Feb 19, 12:48 AM

Mon, Feb 18

ebevhan added inline comments to D58236: Make address space conversions a bit stricter..
Mon, Feb 18, 8:30 AM · Restricted Project
ebevhan added inline comments to D58236: Make address space conversions a bit stricter..
Mon, Feb 18, 8:27 AM · Restricted Project
ebevhan added inline comments to D58346: [Sema] Change addr space diagnostics in casts to follow C++ style.
Mon, Feb 18, 7:45 AM
ebevhan added inline comments to D58236: Make address space conversions a bit stricter..
Mon, Feb 18, 5:31 AM · Restricted Project
ebevhan updated the diff for D58236: Make address space conversions a bit stricter..
Mon, Feb 18, 5:25 AM · Restricted Project

Thu, Feb 14

ebevhan added inline comments to D58236: Make address space conversions a bit stricter..
Thu, Feb 14, 11:10 AM · Restricted Project
ebevhan created D58236: Make address space conversions a bit stricter..
Thu, Feb 14, 7:42 AM · Restricted Project

Wed, Feb 13

ebevhan added a comment to D58060: Fix diagnostic for addr spaces in static_cast.

We had discussion related to this with John earlier. And I documented it in this bug: https://bugs.llvm.org/show_bug.cgi?id=39674

Wed, Feb 13, 3:49 PM
ebevhan added a comment to D58060: Fix diagnostic for addr spaces in static_cast.

So static_cast permits conversions from AS1 to AS2 where that conversion is implicitly allowed, and the new addrspace_cast would permit conversions from AS1 to AS2 where it is explicitly allowed. That seems like it fits in rather well with the idea in D57464 regarding support for specifying permitted AS conversions in target.

Wed, Feb 13, 8:45 AM

Thu, Feb 7

ebevhan added inline comments to D57219: [Fixed Point Arithmetic] Fixed Point Comparisons.
Thu, Feb 7, 4:18 AM · Restricted Project
ebevhan added inline comments to D57219: [Fixed Point Arithmetic] Fixed Point Comparisons.
Thu, Feb 7, 2:21 AM · Restricted Project
ebevhan added inline comments to D56900: [Fixed Point Arithmetic] Fixed Point and Integer Conversions.
Thu, Feb 7, 1:57 AM · Restricted Project
ebevhan added a comment to D57553: [Fixed Point Arithmetic] Avoid resizing for types with the same width.

In regards to solving the problem of resizing for int conversions, I'm starting to think that we will need that initial resize since if we want to retain the min-max pattern for all conversions, then it would be necessary to extend and shift when converting from an int to fixed point. Otherwise, I think we'd have the initial pattern I proposed where we check against the source value, but not have this pattern.

Thu, Feb 7, 1:37 AM · Restricted Project
ebevhan added inline comments to D55720: [Intrinsic] Signed Fixed Point Saturation Multiplication Intrinsic.
Thu, Feb 7, 12:34 AM · Restricted Project

Wed, Feb 6

ebevhan added a comment to D57464: Generalize method overloading on addr spaces to C++.

Moving parsed attributes between lists isn't unreasonable if that's what you have to do; we already do that when processing the ObjC ARC qualifiers. The ambiguity with function attributes is pretty much inherent.

Wed, Feb 6, 2:31 AM

Tue, Feb 5

ebevhan added inline comments to D57464: Generalize method overloading on addr spaces to C++.
Tue, Feb 5, 5:37 AM
ebevhan added inline comments to D57464: Generalize method overloading on addr spaces to C++.
Tue, Feb 5, 1:59 AM

Fri, Feb 1

ebevhan added inline comments to D57464: Generalize method overloading on addr spaces to C++.
Fri, Feb 1, 2:14 PM
ebevhan added inline comments to D57464: Generalize method overloading on addr spaces to C++.
Fri, Feb 1, 8:09 AM
ebevhan added a comment to D57553: [Fixed Point Arithmetic] Avoid resizing for types with the same width.

This doesn't seem to address the particular case in the integer conversion patch. In fact, I don't see those conversions at all.

Fri, Feb 1, 12:50 AM · Restricted Project

Thu, Jan 31

ebevhan added inline comments to D57464: Generalize method overloading on addr spaces to C++.
Thu, Jan 31, 5:50 AM

Wed, Jan 30

ebevhan added inline comments to D57464: Generalize method overloading on addr spaces to C++.
Wed, Jan 30, 3:21 PM

Mon, Jan 28

ebevhan added inline comments to D57219: [Fixed Point Arithmetic] Fixed Point Comparisons.
Mon, Jan 28, 12:14 AM · Restricted Project

Fri, Jan 25

ebevhan created D57226: [Fixed Point] [AST] Add an AST serialization code for fixed-point literals..
Fri, Jan 25, 3:41 AM
ebevhan added inline comments to D57226: [Fixed Point] [AST] Add an AST serialization code for fixed-point literals..
Fri, Jan 25, 3:41 AM
ebevhan added inline comments to D57219: [Fixed Point Arithmetic] Fixed Point Comparisons.
Fri, Jan 25, 1:51 AM · Restricted Project
ebevhan added inline comments to D56900: [Fixed Point Arithmetic] Fixed Point and Integer Conversions.
Fri, Jan 25, 12:44 AM · Restricted Project

Thu, Jan 24

ebevhan added inline comments to D55850: [OpenCL] Allow address spaces as method qualifiers.
Thu, Jan 24, 6:07 AM
ebevhan added a comment to D55850: [OpenCL] Allow address spaces as method qualifiers.

I think the code that comes to mind is mostly like in GetTypeSourceInfoForDeclarator:

LangAS AS =
    (ASIdx == LangAS::Default ? LangAS::opencl_generic : ASIdx);

It's behind an OpenCLCPlusPlus guard so it won't add generic on anything if it's not OpenCL++, but there shouldn't be a reason why the rest of the code in that block won't work for regular C++.

Thu, Jan 24, 12:30 AM

Tue, Jan 22

ebevhan added a comment to D55850: [OpenCL] Allow address spaces as method qualifiers.

Okay, sounds good! I'm not a C++ expert, but I'd be happy to look at the patches when they're up. Haven't done much serious testing on my end so far, but from what I've seen the patches so far look good!

Tue, Jan 22, 3:45 AM

Jan 21 2019

ebevhan added a comment to D55850: [OpenCL] Allow address spaces as method qualifiers.

I'm a bit late to the party here, it was an older patch so I wasn't watching this one.

Jan 21 2019, 8:25 AM
ebevhan added inline comments to D56900: [Fixed Point Arithmetic] Fixed Point and Integer Conversions.
Jan 21 2019, 7:26 AM · Restricted Project

Jan 18 2019

ebevhan added inline comments to D56900: [Fixed Point Arithmetic] Fixed Point and Integer Conversions.
Jan 18 2019, 1:31 AM · Restricted Project

Jan 15 2019

ebevhan added inline comments to D55868: [Fixed Point Arithmetic] Fixed Point Addition Constant Expression Evaluation.
Jan 15 2019, 8:07 AM · Restricted Project

Jan 7 2019

ebevhan added inline comments to D56066: [OpenCL] Address space for default class members.
Jan 7 2019, 1:41 AM

Dec 20 2018

ebevhan added inline comments to D55868: [Fixed Point Arithmetic] Fixed Point Addition Constant Expression Evaluation.
Dec 20 2018, 8:21 AM · Restricted Project

Dec 19 2018

ebevhan added a comment to D55720: [Intrinsic] Signed Fixed Point Saturation Multiplication Intrinsic.

Nothing sticks out to me, so I think it looks good. Hard to tell if there are any sneaky edge cases in the lowering steps, though.

Dec 19 2018, 8:18 AM · Restricted Project

Dec 18 2018

ebevhan added a comment to D51211: [Sema] Emit -Wformat properly for bitfield promotions..

Thanks, that would be great! Hopefully it will work this time.

Dec 18 2018, 7:10 AM
ebevhan updated the diff for D51211: [Sema] Emit -Wformat properly for bitfield promotions..

Use auto.

Dec 18 2018, 12:27 AM
ebevhan added inline comments to D51211: [Sema] Emit -Wformat properly for bitfield promotions..
Dec 18 2018, 12:26 AM
ebevhan added inline comments to D55656: [OpenCL] Address space for default class members.
Dec 18 2018, 12:23 AM

Dec 17 2018

ebevhan added a comment to D54862: [OpenCL] Add generic AS to 'this' pointer.

I'm also a bit confused about the semantics that this patch is applying to function types. It mostly seems to concern the extra trailing Qualifiers on CXXMethodDecl to store the addrspace quals, but in some places (SemaType:4842, SemaDecl:3198) it seems to be applying the address space to the function type itself, which certainly seems like something else to me. A function with an address space qualified type would (to me, at least) be a function *located* in that address space, not one qualified to take a this from that address space.

Dec 17 2018, 3:37 PM
ebevhan added inline comments to D54862: [OpenCL] Add generic AS to 'this' pointer.
Dec 17 2018, 7:46 AM

Dec 14 2018

ebevhan added a comment to D55625: [Intrinsic] Unsigned Fixed Point Multiplication Intrinsic.

Maybe a test with scale == bitwidth? Other than that it looks good to me.

Dec 14 2018, 6:37 AM · Restricted Project

Dec 12 2018

ebevhan requested review of D51211: [Sema] Emit -Wformat properly for bitfield promotions..
Dec 12 2018, 7:08 AM
ebevhan updated the diff for D51211: [Sema] Emit -Wformat properly for bitfield promotions..

Fix the build failures (caused by default argument promotion of float vectors).

Dec 12 2018, 2:41 AM
ebevhan added a comment to D51211: [Sema] Emit -Wformat properly for bitfield promotions..

Hmm, sorry about that. I'll have a look.

Dec 12 2018, 12:23 AM

Dec 11 2018

ebevhan added a comment to D51211: [Sema] Emit -Wformat properly for bitfield promotions..

I don't have commit access, so I would appreciate it if you could commit the change.

Dec 11 2018, 8:02 AM

Dec 7 2018

ebevhan added inline comments to D54719: [Intrinsic] Signed Fixed Point Multiplication Intrinsic.
Dec 7 2018, 1:33 AM
ebevhan added inline comments to D54719: [Intrinsic] Signed Fixed Point Multiplication Intrinsic.
Dec 7 2018, 1:16 AM

Dec 5 2018

ebevhan added inline comments to D53738: [Fixed Point Arithmetic] Fixed Point Addition.
Dec 5 2018, 8:24 AM · Restricted Project
ebevhan added inline comments to D53738: [Fixed Point Arithmetic] Fixed Point Addition.
Dec 5 2018, 7:34 AM · Restricted Project

Dec 4 2018

ebevhan added inline comments to D54719: [Intrinsic] Signed Fixed Point Multiplication Intrinsic.
Dec 4 2018, 3:39 AM
ebevhan updated the diff for D51211: [Sema] Emit -Wformat properly for bitfield promotions..

Added testing for C++ and different sizes of int and long.

Dec 4 2018, 2:18 AM
ebevhan added inline comments to D51211: [Sema] Emit -Wformat properly for bitfield promotions..
Dec 4 2018, 2:10 AM

Dec 3 2018

ebevhan added inline comments to D51211: [Sema] Emit -Wformat properly for bitfield promotions..
Dec 3 2018, 6:57 AM
ebevhan added inline comments to D51211: [Sema] Emit -Wformat properly for bitfield promotions..
Dec 3 2018, 6:36 AM
ebevhan added inline comments to D53738: [Fixed Point Arithmetic] Fixed Point Addition.
Dec 3 2018, 5:55 AM · Restricted Project
ebevhan added a comment to D54719: [Intrinsic] Signed Fixed Point Multiplication Intrinsic.

LGTM.

Dec 3 2018, 5:38 AM
ebevhan added inline comments to D51211: [Sema] Emit -Wformat properly for bitfield promotions..
Dec 3 2018, 5:24 AM

Nov 30 2018

ebevhan updated the diff for D51211: [Sema] Emit -Wformat properly for bitfield promotions..

Rebased and addressed review comments.

Nov 30 2018, 8:14 AM
ebevhan added a reviewer for D51211: [Sema] Emit -Wformat properly for bitfield promotions.: aaron.ballman.
Nov 30 2018, 6:18 AM
ebevhan added inline comments to D53738: [Fixed Point Arithmetic] Fixed Point Addition.
Nov 30 2018, 12:37 AM · Restricted Project

Nov 29 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

Generally I think it's good! One final note; I assume we could technically reuse/rename the EmitFixedPointAdd function and use it to emit other binops when those are added?

Yes, but I imagine if we choose to keep the call to EmitFixedPointConversion to cast both operands to a common type, this wouldn't be reused for division or multiplication since I believe those do not require for the operands to be converted to a common type.

They don't? The example given by the spec is even int * _Fract.

Oh, I meant that the scales of both operands won't need to be aligned before performing the operation. Since for multiplication, we can multiply fixed point numbers in any scale without shifting and only need to perform a shift on the result to convert to the destination type. Although this would only apply to non-saturating multiplication since to use the intrinsics, both operands would need to be in the same scale.

Nov 29 2018, 7:04 AM · Restricted Project

Nov 27 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

Generally I think it's good! One final note; I assume we could technically reuse/rename the EmitFixedPointAdd function and use it to emit other binops when those are added?

Yes, but I imagine if we choose to keep the call to EmitFixedPointConversion to cast both operands to a common type, this wouldn't be reused for division or multiplication since I believe those do not require for the operands to be converted to a common type.

Nov 27 2018, 12:07 AM · Restricted Project

Nov 22 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

@ebevhan Any more comments on this patch?

Nov 22 2018, 12:11 AM · Restricted Project

Nov 21 2018

ebevhan added inline comments to D54719: [Intrinsic] Signed Fixed Point Multiplication Intrinsic.
Nov 21 2018, 1:37 AM

Nov 20 2018

ebevhan added inline comments to D54719: [Intrinsic] Signed Fixed Point Multiplication Intrinsic.
Nov 20 2018, 6:32 AM

Nov 16 2018

ebevhan added inline comments to D53738: [Fixed Point Arithmetic] Fixed Point Addition.
Nov 16 2018, 8:52 AM · Restricted Project

Nov 15 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

I'd be interested in seeing tests for two saturating unsigned _Fract with and without padding.

Nov 15 2018, 1:08 AM · Restricted Project

Nov 14 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

The only thing I didn't include in this patch were the suggested changes to FixedPointSemantics which would indicate if the semantics were original from an integer type. I'm not sure how necessary this is because AFAIK the only time we would need to care if the semantics came from an int is during conversion from a fixed point type to an int, which should only occur during casting and not binary operations. In that sense, I don't think this info needs to be something bound to the semantics, but more to the conversion operation. I also don't think that would be relevant for this patch since all integers get converted to fixed point types anyway and not the other way around.

Nov 14 2018, 7:21 AM · Restricted Project

Nov 13 2018

ebevhan created D54468: [LoadStoreVectorizer] Fix infinite loop in reorder..
Nov 13 2018, 2:07 AM · Restricted Project

Nov 6 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

Not out of line with other features that significantly break with what's expressible. But the easy alternative to storing the intermediate "type" in the AST is to just provide a global function that can compute it on demand.

Yeah, it might just be simpler to go the route of not storing the computation semantic in the AST, at least for now. That's fairly similar to the solution in the patch, so I feel a bit silly for just going around in a circle.

To make that work I think the patch needs some changes, though. There should be a function in FixedPointSemantics to find the common full-precision semantic between two semantics, and the getFixedPointSemantics in ASTContext should be amended to take integer types (or another method should be provided for this, but that one already exists). I think that the FixedPointConversions method should also be embedded into the rest of UsualArithmeticConversions as there shouldn't be any need to have it separate. You still want to do the rvalue conversion and other promotions, and the rules for fixed-point still fit into the arithmetic conversions, even in the spec.

EmitFixedPointConversion should be changed to take FixedPointSemantics rather than QualType. This has a couple of downsides:

  • It can no longer handle floating point conversions. They would have to be handled in EmitScalarConversion.
  • Conversion from integer is fine, but conversion to integer cannot be generalized away with the fixed-point semantics as they are currently, as that kind of conversion must round towards zero. This requires a rounding step for negative numbers before downscaling, which the current code does not do. Is there a better way of generalizing this?

FixedPointSemantics is free to do whatever is convenient for the representation; if it helps to make it able to explicitly represent an integral type — and then just assert that it's never in that form when it's used in certain places, I think that works. Although you might consider making a FixedPointOrIntegralSemantics class and then making FixedPointSemantics a subclass which adds nothing to the representation but semantically asserts that it's representing a fixed-point type.

Nov 6 2018, 12:47 AM · Restricted Project

Nov 5 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.
  1. The question is easily answered by pointing at the language spec. The language does not say that the operands are promoted to a common type; it says the result is determined numerically from the true numeric values of the operands.

I guess. I just see that as a behavioral specification and not necessarily an implementation detail. It's perfectly acceptable to implement it as promotion to a common type (obviously, as that's what we are going to do), and I don't really see this as the spec putting any kind of requirement on how the implementation should be done.

Of course it's a behavioral specification. All I'm saying is that the implementation detail of how we perform these operations isn't really reasonable or appropriate to express in the AST. I know it's a bit fuzzy because of some of the things we do with e.g. opaque values and so on, but the AST is not meant to be a completely implementation-defined IR; it tries to capture the formal semantics of the program including "official" conversions and so on. Integer addition is specified as converting its arguments to a common type and then performing a homogenous operation in that type. Fixed-point addition is not; it's specified as doing a heterogenous operation on the original (well, rvalue-converted) operand types.

Nov 5 2018, 3:44 AM · Restricted Project

Nov 1 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

Well, it could be passed around through most code as some sort of abstractly-represented intermediate "type" which could be either a QualType or a fixed-point semantics.

Sounds to me like you're describing a new Type that can contain an arbitrary fixed-point semantic :)

The fact that it doesn't exist in the modeled type system is important.

The arbitrary-type overflow intrinsics have this same problem, and we did not try to solve it by creating a new type class for arbitrary-precision integers and promoting the arguments.

Nov 1 2018, 10:07 AM · Restricted Project
ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

Well, it could be passed around through most code as some sort of abstractly-represented intermediate "type" which could be either a QualType or a fixed-point semantics.

Nov 1 2018, 8:20 AM · Restricted Project

Oct 31 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

Well, maybe the cleanest solution would be to actually fold CompoundAssignOperator back into BinaryOperator and just allow BinaryOperator to optionally store information about the intermediate type of the computation and how the operands need to be promoted. That information could be elided in the common cases where it's trivial, of course.

Oct 31 2018, 2:27 AM · Restricted Project

Oct 30 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

The important difference would be that we separate the semantics of performing the conversion and the operation. I understand that adding a new type could be a bit more involved than baking the conversion into the operator, but I really do not enjoy seeing so much implicit, implementation-specific logic encapsulated in the same AST element. Anyone who wants to look at BinaryOperators with fixed-point types will need to know all of the details of how the finding the common type and conversion is done, rather than simply "it does an addition".

It's not just that adding a new type is "involved", it's that it's a bad solution. Those types can't actually be expressed in the language, and changing the type system to be able to express them is going to lead to a lot of pain elsewhere.

Oct 30 2018, 3:47 AM · Restricted Project

Oct 29 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

I don't think we should add *types* just for this, but if you need to make a different kind of BinaryOperator that represents that the semantics aren't quite the same (the same way that the compound assignments have their own subclass), that seems natural to me.

Oct 29 2018, 1:16 AM · Restricted Project

Oct 26 2018

ebevhan added a comment to D53738: [Fixed Point Arithmetic] Fixed Point Addition.

I think I've already expressed that I'm not at all a fan of encoding the full-precision logic in the operations themselves and not explicitly in the AST. We already have (well, not yet, but we will) routines for emitting conversions to/from/between fixed-point types of arbitrary semantics - why not use that instead of reimplementing the same logic for every binary operation?

Oct 26 2018, 3:37 AM · Restricted Project

Oct 22 2018

ebevhan added inline comments to D53308: [Fixed Point Arithmetic] Fixed Point to Boolean Cast.
Oct 22 2018, 7:17 AM · Restricted Project
ebevhan closed D52306: [DAGCombine] Don't fold dependent loads across SELECT_CC..
Oct 22 2018, 3:46 AM
ebevhan added 1 commit(s) for D52306: [DAGCombine] Don't fold dependent loads across SELECT_CC.: rL342980: [DAGCombine] Don't fold dependent loads across SELECT_CC..
Oct 22 2018, 3:46 AM
ebevhan added an edge to rL342980: [DAGCombine] Don't fold dependent loads across SELECT_CC.: D52306: [DAGCombine] Don't fold dependent loads across SELECT_CC..
Oct 22 2018, 3:46 AM

Oct 17 2018

ebevhan added a comment to D53340: [Intrinsic] Unigned Saturation Addition Intrinsic.

In our implementation we lower addition of two saturated unsigned fixed point types to sadd.sat (if the input values are in the range [0, SIGNED_MAX] the result will be in the range [0, SIGNED_MAX] as well). So we haven't really found a need for implementing uadd.sat.

Oct 17 2018, 1:20 AM

Oct 16 2018

ebevhan added inline comments to D53308: [Fixed Point Arithmetic] Fixed Point to Boolean Cast.
Oct 16 2018, 1:07 AM · Restricted Project

Oct 15 2018

ebevhan added inline comments to D50616: [Fixed Point Arithmetic] FixedPointCast.
Oct 15 2018, 3:33 AM · Restricted Project

Oct 12 2018

ebevhan added a comment to D53053: [Intrinsic] Signed Saturation Addition Intrinsic.

Looks good to me!

Oct 12 2018, 12:13 AM

Oct 11 2018

ebevhan added inline comments to D53053: [Intrinsic] Signed Saturation Addition Intrinsic.
Oct 11 2018, 12:54 AM

Oct 10 2018

ebevhan added inline comments to D53053: [Intrinsic] Signed Saturation Addition Intrinsic.
Oct 10 2018, 12:48 AM
ebevhan added inline comments to D53053: [Intrinsic] Signed Saturation Addition Intrinsic.
Oct 10 2018, 12:41 AM
ebevhan added a comment to D50616: [Fixed Point Arithmetic] FixedPointCast.

I agree with John, after that I think it's fine for me.

Oct 10 2018, 12:01 AM · Restricted Project

Oct 9 2018

ebevhan added a comment to D52286: [Intrinsic] Signed Saturation Intrinsic.

If the use of a special intrinsic for saturation is rare (few targets that supports it natively), then perhaps we should put this particular patch on hold for now?

I guess the target that @bevinh (and I) is working on can override the codegen in clang to select our target specific intrinsic just like we do today. Or is it hard to do target specific overrides in clang codegen?

Oct 9 2018, 12:29 AM
ebevhan added a comment to D52286: [Intrinsic] Signed Saturation Intrinsic.

Here is a module with the function right after expansion. This is generated for x86 and not our target so both this IR and the result will probably be slightly different than what I posted.

target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
Oct 9 2018, 12:07 AM

Oct 8 2018

ebevhan added a comment to D52286: [Intrinsic] Signed Saturation Intrinsic.

I've been experimenting a bit with early expansion of our sat intrinsic to see how the code generation is affected by it. In general, it doesn't actually seem like there's much of an effect. In fact, neither our benchmarks nor the user code I'm looking at seem to be terribly affected by expanding the intrinsic. This is probably due to most of the instances of saturation being 'locked down' by surrounding intrinsics.

Oct 8 2018, 2:03 AM