Re: [PATCH] fold-const.c use of BRANCH_COST

[Jan Hubicka <jh at suse dot cz>]

> >>>>> Jan Hubicka writes:
> 
> Jan> I would like to see this happen.  Definitly i386 CPUs are other where
> Jan> BRANCH_COST choice doesn't match.  It would be nice to have separate
> Jan> knobs for when optimizing for size or speed (decided using
> Jan> maybe_hot_bb_p inside ifcvt.c)
> 
> 	If we are going to separate all of the thresholds, should they be
> target hooks or macros?

I believe we are mocing from macros to the hooks, so it should be hook.
I think it can be a bitmap (ie one value) so we don't need to have so
many of them.  This opens a question how we will deal with adding new
transformations....
> 
> The basic breakdown is the following:
> 
> 1) ifcvt.c
>   a) MAX_CONDITIONAL_EXECUTE (BRANCH_COST + 1)
>   b) store_flag normalize (true/false BRANCH_COST >= 2)
>   c) store_flag normalize (default BRANCH_COST >= 3)
>   d) store_flag addcc (BRANCH_COST >= 2)
>   e) store_flag mask (BRANCH_COST >= 2)
>   f) cmove arith (BRANCH_COST >= 5)
> 
> 2) expmed.c
>   a) div quotient jump vs shift (BRANCH_COST < 1 or < 3)
>   b) emit_store_flag SCC (BRANCH_COST > 0)
> 
> 3) expr.c
>   a) trinary const (BRANCH_COST >= 3)
>        call do_store_flag cheap (BRANCH_COST <= 1)
>   b) do_store_flag SCC (BRANCH_COST >= 0)
> 
> 4) fold-const.c
>   a) range_test short-circuit (BRANCH_COST >= 2)
>   b) fold_truthop unconditionally evaluate RHS (BRANCH_COST >= 2)

optabs.c for instance is missing in your list.

Honza
> 
> 
> David