On 10/29/2014 11:59 PM, Matt Turner wrote:
> On Wed, Oct 29, 2014 at 6:11 PM, Thomas Helland
> <thomashellan...@gmail.com> wrote:
>> This series does some initial work to make expansion of
>> the get_range function a lot cleaner.
>> It also adds a couple simple initial ranges.
>> These patches are by no means perfect, but I hope
>> they will provide some feedback and ideas.
>> I'm hoping to expand this to do the following:
>> -Add get_range for most opcodes I can think of
>> -Add more utility functions to the constant_util file.
>> -Repurpose the file to optimize more than just min/max.
>> -Elimintate if's that we know the result of
>> -Whatever pops into my head
>
> Sounds good.
>
>> I have some questions about undefined behaviour regarding this.
>> Do we have anyway of signaling in our IR that
>> the variable is the result of undefined behaviour?
>>
>> In compilers like llvm, if I recall, they have a flag for this
>> so they can signal undefined behaviour and use whatever value
>> gives the most efficient code for its uses.(used in -ffast-math).
>>
>> A hypotetichal situation:
>> We find that we have sqrt(x) where x has upper bound < 0.
>> The spec says the behavior is undefined for x < 0.
>> The same applies for inverse sqrt, log, log2 and pow.
>> How should this be handled?
>> Should a warning be issued?
>> Could we simplify this to a constant 0?
>> That would allow more optimizations to occur.
>
> That's probably what I'd try first.
>
> I applied your series and ran our internal shader-db through it. The
> good news is that it helps some programs!
>
> The bad news is that it hurts even more programs. I randomly selected
> two, and the relevant diffs looked like this:
>
> -math.sat exp(8) g91<1>F g86<8,8,1>F null {
> align1 1Q compacted };
> +math exp(8) g91<1>F g85<8,8,1>F null {
> align1 1Q compacted };
> +sel.l(8) g92<1>F g91<8,8,1>F 1F { align1 1Q
> };
>
> So we're saying we know the result of exp() must be >= 0, so no need
> to handle the lower bound. Instead just clamp the top. Except saturate
> is free and just clamping the top is not.
>
> Disabling ir_unop_exp/ir_unop_exp2 from patch 6/6 shows some programs
> actually do benefit from this optimization though. Before, they did
> things like:
>
> math exp(8) g17<1>F g14<8,8,1>F null {
> align1 1Q compacted };
> sel.ge(8) g124<1>F g17<8,8,1>F 0F {
> align1 1Q compacted };
>
> That tells me that there are gains to be had here. We just have to
> figure out how.
>
> I'm not exactly sure how the best way to handle this is, but it seems
> like we want to trim useless clamps *iff* they cannot be paired with
> another to form a saturate.
Would it be sufficient to do ir_unop_saturate generation before this
pass? Or is the pass breaking the saturate up? Also... wasn't Eric
saying his platform didn't have free saturates?
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
