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: [PATCH][3/4] Fix PR54733 Optimize endian independent load/store


Please find attached the new version of this patch addressing all suggestions
given. I splat the patch into 2 to ease the review: part3 only split stmt
manipulation out of optimize_bswap into replace_bswap while part4
contains all the changes needed to support load in host endianness
(as opposed to byteswap). Part 4 is sent in a separate email.

I also have a few comments.

> From: Richard Biener [mailto:richard.guenther@gmail.com]
> 
> Yes, the sign matters - I forgot about that.  Eventually the load type
> should be just chosen from the target type though.

Do you mean making a load directly in the right signedness? There still remains
The possibility of the load being of a different size than the target type
(difference between range and size explained in the comments of
struct symbolic_number).

> 
> >>
> >> You seem to replace the stmt computing the target value by directly
> >> loading into the target.  IMHO that's premature optimization and it
> >> would be easier to just replace its rhs (that way the stmt still has
> >> a proper location for example).

I changed to just replace its rhs but you'll notice that the code is bigger and
there is a bit of duplication. However, I didn't replace the original code as
gimple_build_call creates a statement, not a tree that could replace the
rhs. Also replacing the rhs could only be done if no load was done prior
as else a statement is already created before.

ChangeLog are now as follows:

*** gcc/ChangeLog ***

2014-05-04  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	PR tree-optimization/54733
	* tree-ssa-math-opts.c (execute_optimize_bswap): Move its leading
	comment back in place. Also split statement transformation into ...
	(bswap_replace): This.

Is it ok for stage1?

Best regards,

Thomas Preud'homme

Attachment: gcc32rm-84.5.1.part3.diff
Description: Binary data


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