This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Rewrite some jump.c routines to use flags


Eric Botcazou <ebotcazou@adacore.com> writes:
>> gcc/
>> 	* jump.c (FLAGS_EQ, FLAGS_LT, FLAGS_GT, FLAGS_UNORDERED, FLAGS_ORDER)
>> 	(FLAGS_SIGNED, FLAGS_UNSIGNED, FLAGS_SIGN_AGNOSTIC, FLAGS_SIGNEDNESS)
>> 	(FLAGS_TRAP_QNANS, FLAGS_TRAP_SNANS, FLAGS_TRAP_NANS, FLAGS_TRAP_NONE)
>> 	(FLAGS_TRAPS): New constants.
>> 	(condition_to_flags, flags_to_condition): New functions.
>> 	(swap_condition, unsigned_condition, signed_condition)
>> 	(comparison_dominates_p): Use them.
>
> What's the run time cost of this?  In particular, do the first 3 rewritten 
> functions still have a trivial path for EQ/NE/...?  

No, no trivial paths unfortunately.  I'd hoped that inlining and
jump threading would give us very similar code, but no such luck.
condition_to_flags is a table lookup, but then flags_to_condition
is a branch tree.

If that's a concern, I can drop the changes to the existing
functions and just use the new flags for the follow-on patch.

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]