[Mesa-dev] [PATCH 08/18] radeonsi: don't use llvm.AMDIL.fraction for FRC and DFRAC

[Marek Olšák]

On Fri, Jul 31, 2015 at 5:13 PM, Tom Stellard <tom at stellard.net> wrote:
> On Fri, Jul 31, 2015 at 04:59:19PM +0200, Marek Olšák wrote:
>> On Fri, Jul 31, 2015 at 4:18 PM, Tom Stellard <tom at stellard.net> wrote:
>> > On Tue, Jul 28, 2015 at 12:05:43PM +0200, Marek Olšák wrote:
>> >> From: Marek Olšák <marek.olsak at amd.com>
>> >>
>> >> There are 2 reasons for this:
>> >> - LLVM optimization passes can work with floor
>> >> - there are patterns to select v_fract from floor anyway
>> >>
>> >> There is no change in the generated code.
>> >> ---
>> >>  src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 20 ++++++++++++++++----
>> >>  1 file changed, 16 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
>> >> index 319380f..5c08cf5 100644
>> >> --- a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
>> >> +++ b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
>> >> @@ -1170,6 +1170,20 @@ static void emit_dneg(
>> >>                       emit_data->args[0], "");
>> >>  }
>> >>
>> >> +static void emit_frac(
>> >> +             const struct lp_build_tgsi_action * action,
>> >> +             struct lp_build_tgsi_context * bld_base,
>> >> +             struct lp_build_emit_data * emit_data)
>> >> +{
>> >> +     LLVMBuilderRef builder = bld_base->base.gallivm->builder;
>> >> +
>> >> +     LLVMValueRef floor = lp_build_intrinsic(builder, "floor", emit_data->dst_type,
>> >
>> > The intrinsics name should be "llvm.floor.f32" for float and "llvm.floor.f64"
>> > for double.
>> >
>> > With that fixed, this is:
>> > Reviewed-by: Tom Stellard <thomas.stellard at amd.com>
>>
>> Sorry, I have pushed this already. Is it really required to use
>> "llvm.floor.f*"? We've been using "floor" for FLR forever. We've also
>> been using "fabs" and "ceil". Are those wrong too?
>>
>
> It is better to use the intrinsics: (i.e. llvm.*) functions, because
> they don't have side-effects like the libm calls, so they can be optimized
> better.

OK, thanks for the explanation.

Marek