Page MenuHomePhabricator

ebevhan (Bevin Hansson)
User

Projects

User does not belong to any projects.

User Details

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

Recent Activity

Wed, Apr 17

ebevhan updated the diff for D58236: Make address space conversions a bit stricter..
Wed, Apr 17, 1:40 AM · Restricted Project

Tue, Apr 16

ebevhan added a comment to D58236: Make address space conversions a bit stricter..

Well, it doesn't seem to me like there is consensus on prohibiting nested address space conversion like this.

I can simply redo the patch to only include the bugfix on implicit conversions and drop the nesting level checks.

I thought the conclusion is:

  • Explicit conversions allowed for nested pointers with a warning.
  • Implicit conversions are disallowed for nested pointers with an error.

    Do you not see it this way?
Tue, Apr 16, 4:10 AM · Restricted Project

Mon, Apr 15

ebevhan added a comment to D58236: Make address space conversions a bit stricter..

Well, it doesn't seem to me like there is consensus on prohibiting nested address space conversion like this.

Mon, Apr 15, 3:45 AM · Restricted Project

Thu, Apr 11

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

I think I would lean towards the latter since it means less fudging around with a whole bunch of unrelated methods. Do @rjmccall or @rsmith have any further opinions on this?

Ok, I can change the patch to prototype this approach. I might need some example test cases though.

Thu, Apr 11, 1:44 AM

Tue, Mar 26

ebevhan added a comment to D58236: Make address space conversions a bit stricter..

I think C probably requires us to allow this under an explicit cast, but we can at least warn about it. It does not require us to allow this as an implicit conversion, and that should be an error.

Tue, Mar 26, 1:28 PM · Restricted Project

Mar 21 2019

ebevhan added a comment to D58236: Make address space conversions a bit stricter..

Any more input on this?

Mar 21 2019, 4:43 AM · Restricted Project

Mar 14 2019

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

I think not. :( But I am wondering if we could proceed for now in some general direction and then make any improvements later. Probably the biggest part of this patch is not going to change. Would this make sense?

Mar 14 2019, 5:48 AM

Mar 11 2019

ebevhan added inline comments to D59105: [RFC] Create an Arbitrary Precision Integer Type..
Mar 11 2019, 7:47 AM

Mar 7 2019

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

Any more input on this?

Mar 7 2019, 6:11 AM

Mar 5 2019

ebevhan added inline comments to D58060: Fix diagnostic for addr spaces in reference binding.
Mar 5 2019, 6:31 AM

Feb 28 2019

ebevhan added inline comments to D58346: [Sema] Change addr space diagnostics in casts to follow C++ style.
Feb 28 2019, 1:09 AM · Restricted Project
ebevhan added a comment to D58236: Make address space conversions a bit stricter..

LGTM! Thanks a lot for fixing this old bug! Btw, do you plan to look at generalizing this to C++ as well?

Feb 28 2019, 12:46 AM · Restricted Project

Feb 27 2019

ebevhan added inline comments to D58236: Make address space conversions a bit stricter..
Feb 27 2019, 2:19 AM · Restricted Project
ebevhan updated the diff for D58236: Make address space conversions a bit stricter..
Feb 27 2019, 2:18 AM · Restricted Project

Feb 20 2019

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

Feb 19 2019

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

Feb 18 2019

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

Feb 14 2019

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

Feb 13 2019

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

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

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

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.

Feb 13 2019, 8:45 AM

Feb 7 2019

ebevhan added inline comments to D57219: [Fixed Point Arithmetic] Fixed Point Comparisons.
Feb 7 2019, 4:18 AM · Restricted Project
ebevhan added inline comments to D57219: [Fixed Point Arithmetic] Fixed Point Comparisons.
Feb 7 2019, 2:21 AM · Restricted Project
ebevhan added inline comments to D56900: [Fixed Point Arithmetic] Fixed Point and Integer Conversions.
Feb 7 2019, 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.

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

Feb 6 2019

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.

Feb 6 2019, 2:31 AM

Feb 5 2019

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

Feb 1 2019

ebevhan added inline comments to D57464: Generalize method overloading on addr spaces to C++.
Feb 1 2019, 2:14 PM
ebevhan added inline comments to D57464: Generalize method overloading on addr spaces to C++.
Feb 1 2019, 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.

Feb 1 2019, 12:50 AM · Restricted Project

Jan 31 2019

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

Jan 30 2019

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

Jan 28 2019

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

Jan 25 2019

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

Jan 24 2019

ebevhan added inline comments to D55850: [OpenCL] Allow address spaces as method qualifiers.
Jan 24 2019, 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++.

Jan 24 2019, 12:30 AM

Jan 22 2019

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!

Jan 22 2019, 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 · Restricted Project
ebevhan added inline comments to D54719: [Intrinsic] Signed Fixed Point Multiplication Intrinsic.
Dec 7 2018, 1:16 AM · Restricted Project

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 · Restricted Project
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 · Restricted Project
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 · Restricted Project

Nov 20 2018

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

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