Page MenuHomePhabricator

ebevhan (Bevin Hansson)
User

Projects

User does not belong to any projects.

User Details

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

Recent Activity

Fri, Dec 14

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.

Fri, Dec 14, 6:37 AM

Wed, Dec 12

ebevhan requested review of D51211: [Sema] Emit -Wformat properly for bitfield promotions..
Wed, Dec 12, 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).

Wed, Dec 12, 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.

Wed, Dec 12, 12:23 AM

Tue, Dec 11

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.

Tue, Dec 11, 8:02 AM

Fri, Dec 7

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

Wed, Dec 5

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

Tue, Dec 4

ebevhan added inline comments to D54719: [Intrinsic] Signed Fixed Point Multiplication Intrinsic.
Tue, Dec 4, 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.

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

Mon, Dec 3

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

LGTM.

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

Fri, Nov 30

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

Rebased and addressed review comments.

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

Thu, Nov 29

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.

Thu, Nov 29, 7:04 AM · Restricted Project

Tue, Nov 27

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.

Tue, Nov 27, 12:07 AM · Restricted Project

Thu, Nov 22

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

@ebevhan Any more comments on this patch?

Thu, Nov 22, 12:11 AM · Restricted Project

Wed, Nov 21

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

Tue, Nov 20

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

Fri, Nov 16

ebevhan added inline comments to D53738: [Fixed Point Arithmetic] Fixed Point Addition.
Fri, Nov 16, 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

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

Oct 3 2018

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

I'm not sure why you would need an intrinsic at all. Why can't you just emit the IR equivalent from the beginning. This looks the equivalent of doing something like "x = std::min(std::max(x, -2048), 2047)" in C++ which would be implemented in IR with 2 compares and 2 selects. This is not an uncommon pattern to find in real code and we spend a lot of effort to make sure its handled well. Adding an intrinsic means you'll miss out on the constant folding, knownbits, etc that we've already put in for min/max IR patterns.

Oct 3 2018, 1:00 AM

Sep 28 2018

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

I think this looks pretty good to me now. It's probably a good time to add someone who is familiar with DAG as reviewer at this point.

Sep 28 2018, 12:21 AM

Sep 27 2018

ebevhan added inline comments to D52286: [Intrinsic] Signed Saturation Intrinsic.
Sep 27 2018, 6:43 AM

Sep 26 2018

ebevhan added inline comments to D52286: [Intrinsic] Signed Saturation Intrinsic.
Sep 26 2018, 7:18 AM

Sep 25 2018

ebevhan added inline comments to D52286: [Intrinsic] Signed Saturation Intrinsic.
Sep 25 2018, 1:20 AM

Sep 24 2018

ebevhan added a comment to D52306: [DAGCombine] Don't fold dependent loads across SELECT_CC..

Oh, sorry. I should have mentioned that. That would be nice, thanks!

Sep 24 2018, 11:55 PM

Sep 21 2018

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

So if I understand this correctly, we can handle this intrinsic in 2 ways:

  1. The intrinsic gets converted to IR in a pass before touching the DAG.
  2. The intrinsic gets passed to the DAG and gets legalized and lowered to machine code there.

It seems that from the thread, the consensus was for going with (2), but I also see now how things would be much easier just having this run through a pass in (1). If I recall correctly, the main reason for offsetting the intrinsic "expansion" to the DAG was to determine if the intrinsic was supported by the hardware during the legalization steps. If so, couldn't this also be done in a pass when converting the intrinsic to IR in (1)? That is, we determine early in the pass if this intrinsic call is supported by this target. Those that aren't legal get expanded into IR whereas those that are legal get passed to DAG instruction selection.

I think this might avoid the trouble of having to check types and operations in the DAG, and ISel can choose whatever appropriate instructions for whatever supported intrinsic (if that makes sense).

Sep 21 2018, 2:06 AM

Sep 20 2018

ebevhan added a reviewer for D52306: [DAGCombine] Don't fold dependent loads across SELECT_CC.: niravd.
Sep 20 2018, 7:53 AM
ebevhan created D52306: [DAGCombine] Don't fold dependent loads across SELECT_CC..
Sep 20 2018, 7:53 AM
ebevhan added a comment to D51211: [Sema] Emit -Wformat properly for bitfield promotions..

Another ping. Anyone up for reviewing this patch?

Sep 20 2018, 6:30 AM
ebevhan added a comment to D52286: [Intrinsic] Signed Saturation Intrinsic.

I think we need to decide where these intrinsics should be 'lowered' if they aren't legal, and define how to let the target specify legality.

Sep 20 2018, 2:00 AM

Sep 7 2018

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

Ping.

Sep 7 2018, 2:22 AM

Aug 30 2018

ebevhan added a comment to D51426: [Sema] Prohibit function-scope compound literals with address spaces..

I don't have commit access, so it would be appreciated if someone could commit it.

Aug 30 2018, 4:53 AM
ebevhan updated the diff for D51426: [Sema] Prohibit function-scope compound literals with address spaces..

Added Embedded-C clause quote.
Fixed formatting.

Aug 30 2018, 1:41 AM

Aug 29 2018

ebevhan added inline comments to D51426: [Sema] Prohibit function-scope compound literals with address spaces..
Aug 29 2018, 11:59 PM
ebevhan created D51426: [Sema] Prohibit function-scope compound literals with address spaces..
Aug 29 2018, 7:27 AM

Aug 24 2018

ebevhan created D51211: [Sema] Emit -Wformat properly for bitfield promotions..
Aug 24 2018, 4:27 AM

Aug 20 2018

ebevhan added a comment to D50616: [Fixed Point Arithmetic] FixedPointCast.

Would it be simpler instead just to have the logic contained in the virtual function for TargetCodeGenInfo as opposed to returning nullptr since any custom target will end up overriding it anyway and ideally not return nullptr?

I guess that's also possible. I figured it would be clearer to have the generic logic in the more obvious location (CGExprScalar) and fall back to the custom handling if needed. Many of the handlers in TargetCodeGenInfo are empty.

Aug 20 2018, 5:09 AM · Restricted Project

Aug 17 2018

ebevhan added a comment to D50616: [Fixed Point Arithmetic] FixedPointCast.

Sorry I forgot to address this also. Just to make sure I understand this correctly since I haven't used these before: target hooks are essentially for emitting target specific code for some operations right? Does this mean that the EmitFixedPointConversion function should be moved to a virtual method under TargetCodeGenInfo that can be overridden and this is what get's called instead during conversion?

Yes, the thought I had was to have a virtual function in TargetCodeGenInfo that would be called first thing in EmitFixedPointConversion, and if it returns non-null it uses that value instead. It's a bit unfortunate in this instance as the only thing that doesn't work for us is the saturation, but letting you configure *parts* of the emission is a bit too specific.

Aug 17 2018, 12:50 AM · Restricted Project

Aug 16 2018

ebevhan added a comment to D50616: [Fixed Point Arithmetic] FixedPointCast.

I think I've mentioned this before, but I would like to discuss the possibility of adding a target hook(s) for some of these operations (conversions, arithmetic when it comes). Precisely matching the emitted saturation operation is virtually impossible for a target.

Aug 16 2018, 1:43 AM · Restricted Project

Aug 7 2018

ebevhan added a comment to D50278: [Sema] Fix for crash on conditional operation with address_space pointer.

I think the solution to a lot of diagnostic and behavior issues with address spaces is to remove predication on OpenCL. It's a bit odd to have a language feature that is enabled out of the box regardless of langoptions (address spaces) but won't actually work properly unless you're building OpenCL.

Aug 7 2018, 12:33 AM · Restricted Project

Aug 6 2018

ebevhan added inline comments to D49945: [Fixed Point Arithmetic] Fix for FixedPointValueToString.
Aug 6 2018, 4:37 AM · Restricted Project
ebevhan added a comment to D50278: [Sema] Fix for crash on conditional operation with address_space pointer.

When I try the test case on our downstream (and when compiling for our target with an extra flag that enables a bunch of OpenCL-related address space code), I get:

ascrash.c:5:12: error: comparison between ('__attribute__((address_space(1))) char *' and '__attribute__((address_space(2))) char *') which
      are pointers to non-overlapping address spaces
  return x < y ? x : y;
         ~ ^ ~
ascrash.c:5:16: error: conditional operator with the second and third operands of type ('__attribute__((address_space(1))) char *' and
      '__attribute__((address_space(2))) char *') which are pointers to non-overlapping address spaces
  return x < y ? x : y;
               ^ ~   ~

A lot of address space code is hidden behind LangOptions.OpenCL.

Aug 6 2018, 1:39 AM · Restricted Project
ebevhan accepted D49945: [Fixed Point Arithmetic] Fix for FixedPointValueToString.

LGTM.

Aug 6 2018, 1:09 AM · Restricted Project
ebevhan added a comment to D48661: [Fixed Point Arithmetic] Fixed Point Constant.

Sorry for the late response, I've been away.

Aug 6 2018, 1:01 AM · Restricted Project

Jul 4 2018

ebevhan added inline comments to D48661: [Fixed Point Arithmetic] Fixed Point Constant.
Jul 4 2018, 1:32 AM · Restricted Project

Jul 3 2018

ebevhan added inline comments to D48661: [Fixed Point Arithmetic] Fixed Point Constant.
Jul 3 2018, 2:02 AM · Restricted Project

Jun 29 2018

ebevhan added inline comments to D48661: [Fixed Point Arithmetic] Fixed Point Constant.
Jun 29 2018, 7:12 AM · Restricted Project
ebevhan added a comment to D48661: [Fixed Point Arithmetic] Fixed Point Constant.

I also think it would be good with some unit tests for this class once the functionality and interface is nailed down.

Jun 29 2018, 5:00 AM · Restricted Project

Jun 28 2018

ebevhan added inline comments to D48661: [Fixed Point Arithmetic] Fixed Point Constant.
Jun 28 2018, 3:08 AM · Restricted Project

Jun 27 2018

ebevhan added inline comments to D48456: [Fixed Point Arithmetic] Casting between fixed point types and other arithmetic types.
Jun 27 2018, 1:11 AM · Restricted Project
ebevhan added inline comments to D48456: [Fixed Point Arithmetic] Casting between fixed point types and other arithmetic types.
Jun 27 2018, 12:27 AM · Restricted Project

Jun 26 2018

ebevhan added inline comments to D48456: [Fixed Point Arithmetic] Casting between fixed point types and other arithmetic types.
Jun 26 2018, 1:49 AM · Restricted Project
ebevhan added a comment to D46944: [analyzer] Use sufficiently large types for index/size calculation..

Ping.

Jun 26 2018, 1:31 AM

Jun 25 2018

ebevhan added a comment to D48456: [Fixed Point Arithmetic] Casting between fixed point types and other arithmetic types.

Would it be possible to add some form of target hook (perhaps to CodeGenABIInfo, which is already accessed with getTargetHooks) for fixed-point operations (maybe even some conversions)? As I've mentioned earlier, we emit both IR and intrinsics for many of these operations to make instruction selection possible. I suspect that any target that wants to utilize fixed-point effectively will need this as well.

Jun 25 2018, 5:07 AM · Restricted Project

Jun 20 2018

ebevhan added a comment to D47630: [Sema] Allow creating types with multiple of the same addrspace..

Thanks! I do not have commit access, so it would be great if someone could commit this.

Jun 20 2018, 12:30 AM

Jun 19 2018

ebevhan accepted D46915: [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals.
Jun 19 2018, 8:44 AM · Restricted Project
ebevhan added a comment to D46915: [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals.

Just a couple more comments and then I think it looks good.

Jun 19 2018, 7:35 AM · Restricted Project

Jun 18 2018

ebevhan added inline comments to D46915: [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals.
Jun 18 2018, 8:36 AM · Restricted Project

Jun 14 2018

ebevhan added inline comments to D46915: [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals.
Jun 14 2018, 9:37 AM · Restricted Project
ebevhan accepted D46911: [Fixed Point Arithmetic] Addition of the remaining fixed point types and their saturated equivalents.
Jun 14 2018, 6:25 AM · Restricted Project
ebevhan added inline comments to D46915: [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals.
Jun 14 2018, 6:18 AM · Restricted Project

Jun 13 2018

ebevhan added inline comments to D46915: [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals.
Jun 13 2018, 8:20 AM · Restricted Project
ebevhan added inline comments to D46911: [Fixed Point Arithmetic] Addition of the remaining fixed point types and their saturated equivalents.
Jun 13 2018, 4:36 AM · Restricted Project
ebevhan accepted D46911: [Fixed Point Arithmetic] Addition of the remaining fixed point types and their saturated equivalents.

LGTM, but I'm not a code owner so maybe someone else should chime in if they have any input.

Jun 13 2018, 4:34 AM · Restricted Project
ebevhan added inline comments to D46915: [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals.
Jun 13 2018, 1:26 AM · Restricted Project
ebevhan added inline comments to D46915: [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals.
Jun 13 2018, 1:04 AM · Restricted Project

Jun 12 2018

ebevhan added inline comments to D46915: [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point Literals.
Jun 12 2018, 8:57 AM · Restricted Project