On Oct 18, 2014, at 11:52 PM, Chandler Carruth <[email protected]> wrote:
>
> On Fri, Oct 17, 2014 at 11:41 PM, Stephen Canon <[email protected]> wrote:
> What I'm saying is that in the long-term, we'd like to support two modes for
> these operations:
>
> limited-range: In this mode, we use the simple "usual" mathematical
> formulations for multiplication and division (no careful handling of overflow
> or underflow or invalid cases). This is like finite-math restricted to
> complex arithmetic expressions (in particular, we don't want to require users
> enable finite-math to get this behavior; we may want this behavior to be the
> default).
>
> no-limited-range: We unconditionally call to compiler-rt for complex mul and
> div operations, and make the compiler-rt implementations correct w.r.t. flags.
>
> The current state of affairs is similar to supporting only no-limited-range,
> except that the compiler-rt implementations may need to be fixed up (I'm
> happy to do that work). This patch puts us somewhere in between the two
> modes, which is a better place for most users, but still slightly worse than
> where I'd really like to be headed.
>
> Thanks, I understand better where you're asking to go.
>
> I think what I would suggest is that whatever fixes are needed for flags in
> the compiler-rt implementation are also applied to the "inlined" bit of code,
> and that we still generate a little bet of inline code in no-limited-range
> and branch to the library call only when complex logic will be required. My
> hope is that both the compiler-rt implementation and this inlined bit of
> logic can be fixed w.r.t. flags and we can allow the common case to not go
> through an actual libcall in no-limited-range.
>
> Does that make sense or seem achievable? If so, then I think this patch is an
> OK first step, and whenever we start pushing on fixes for flags, we apply
> them to both compiler-rt and this code.
>
> If that doesn't seem achievable, then I agree, this patch may just be pushing
> us in the wrong direction.
Sounds reasonable to me. Let's continue with this patch.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
