This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC does not support *mmintrin.h with function specific opts
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Sriraman Tallam <tmsriram at google dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Diego Novillo <dnovillo at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, David Li <davidxl at google dot com>
- Date: Tue, 14 May 2013 13:02:55 +0200
- Subject: Re: GCC does not support *mmintrin.h with function specific opts
- References: <CAAs8HmyBKhjMKyu7aFqn2AU4RGXoCvLP=AwKV+hVS31Wb=FuRg at mail dot gmail dot com> <CAAs8HmzMfRvw19nxu5khXHKoM+Oz63KJSnzy=5WfZHdODF5izw at mail dot gmail dot com> <CAAs8Hmx7YVLJoLNVKy=52SykLB+hqOYWvB9iQUd+g1ZH6mKOCw at mail dot gmail dot com> <CAAs8Hmy34GY0c1PNyvtGW3vtHZ_cVY+PRy0tLuAuvvP8=FaREA at mail dot gmail dot com> <CAAs8HmzO4Mx1W-+RbmhhOH6nNLRQ5TtNeaqpxR-AS0ZR_9vuzw at mail dot gmail dot com> <CAMe9rOomjVGV5rpqRkLqPB530uEPYMcVGU6hAScbjs2eeW-etg at mail dot gmail dot com> <CAFULd4YNGAfhwao+ZKVuHTE1uvqiB04qrdX5FeZxBcVw0Yr1TQ at mail dot gmail dot com> <20130514083913 dot GJ1377 at tucnak dot redhat dot com> <20130514100419 dot GM1377 at tucnak dot redhat dot com> <CAFiYyc2PAZFzA7MDEib+7gXLLmw3HvWvWjLc_qXOwF-nSMvOoA at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, May 14, 2013 at 12:22:05PM +0200, Richard Biener wrote:
> > The problem is that in the first testcase, the VAR_DECL c (guess also b and
> > a) have TYPE_MODE (TREE_TYPE (c)) == V8SFmode (this is dynamic, for vector
> > types TYPE_MODE is a function call), but DECL_MODE (c) is BLKmode
> > (it has been laid out while -mno-avx has been the current) and also
> > DECL_RTL which is a mem:BLK. Guess expr.c would need to special case
> > TREE_STATIC or DECL_EXTERNAL VAR_DECLs with vector type, if they have
> > DECL_MODE BLKmode, but TYPE_MODE some vector type, just adjust the MEM
> > to the desired mode?
--- gcc/expr.c.jj 2013-05-14 08:25:40.000000000 +0200
+++ gcc/expr.c 2013-05-14 12:55:46.331983406 +0200
@@ -9310,6 +9310,8 @@ expand_expr_real_1 (tree exp, rtx target
set_curr_insn_location (saved_loc);
if (REG_P (r) && !REG_EXPR (r))
set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r);
+ if (MEM_P (r) && GET_MODE (r) == BLKmode && mode != BLKmode)
+ r = adjust_address (r, mode, 0);
return r;
}
fixes the ICE on that testcase.
> I think any entity with static storage (maybe even automatic storage) should
> have BLKmode (or rather its mode should not matter) and what matters
> is the mode we use for the access - that is, the mode of the MEM_REF we
> expand, for example.
There wasn't any MEM_REF in that case, just SSA_NAME with SSA_NAME_DEF_STMT
of a load from VAR_DECL.
> That TYPE_MODE is dynamic for vector types is a bad thing. It also means
> that type layout may be variable (consider PPC where double has different
> alignment in structs, so what layout would a struct with a vector_size(16)
> double vector get with -mvsx vs. -mno-vsx?)
I haven't introduced the dynamic TYPE_MODE, but getting rid of it would be
terribly hard I'm afraid. Anyway, if struct layout depends on modes and
handles the vector modes differently from BLKmode, then it is a target bug,
it really should look at the types instead. Otherwise if you have
such struct in a header, then -mvsx code will be ABI incompatible with
-mno-vsx code using the same header.
Jakub