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: [omp4]


On Mon, Nov 04, 2013 at 09:12:10AM -0700, Aldy Hernandez wrote:
> On 11/04/13 08:44, Jakub Jelinek wrote:
> >On Mon, Nov 04, 2013 at 08:19:12AM -0700, Aldy Hernandez wrote:
> >>Hi.
> >>
> >>While looking over some of your testcases I noticed that array
> >>subscripts are not being properly adjusted:
> >>
> >>foo(int i) {
> >>	array[i] = ....
> >>}
> >>
> >>The `i' should use the simd array magic instead of ICEing :).
> >>
> >>Is the attached patch OK for the branch?
> >
> >I guess short time yes, but I wonder if it wouldn't be better to use
> >walk_gimple_op and do all changes in the callback.  Instead of passing
> >adjustments pass around a struct containing the adjustments, current stmt
> >and the modified flag.  You can use the val_only and is_lhs to determine
> >what you need to do (probably need to reset those two for the subtrees
> >to val_only = true, is_lhs = false and not walk subtrees of types) and you
> >could (if not val_only) immediately gimplify it properly (insert temporary
> >SSA_NAME setter before resp. store after depending on is_lhs).
> >Then you could avoid the regimplification.
> >
> 
> You mean rewrite the entire ipa_simd_modify_function_body() with
> walk_gimple_op and friends, or just the bits I suggested with the
> above patch (the LHS operands in a GIMPLE_ASSIGN)?

Most of the ipa_simd_modify_function_body function, yes.
Perhaps you can't easily handle that way say GIMPLE_RETURN or something, but
generally for other random statements I don't see why it couldn't work
easily.

	Jakub


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