Re: Typecasting information in MEM[...] GIMPLE
On Mon, Jul 27, 2015 at 4:43 PM, Uday P. Khedker wrote: > > > Jakub Jelinek wrote on Monday 27 July 2015 03:50 PM: >> >> On Mon, Jul 27, 2015 at 03:35:45PM +0530, Uday Khedker wrote: >>> >>> We are interested in extracting the type of a tree node that appears >>> within >>> MEM_REF. >>> >>> Given a C program: >>> >>> struct node * * pvar; >>> struct node qvar; >>> pvar = (struct node * *) malloc (sizeof (struct node *)); >>> *pvar = &qvar; >>> >>> It is transformed into the following GIMPLE code: >>> >>> void * * pvar.1; >>> void * pvar.0; >>> pvar.0_1 = malloc (4); >>> pvar = pvar.0_1; >>> MEM[(struct node * *)pvar.0_1] = &qvar; >>> >>> We wish to discover the type of the argument of MEM[...] in the last >>> GIMPLE statement. We can see from the GIMPLE dump that the argument's >>> type is "struct node * *". How do we extract this from the tree >>> definition of MEM[...]? >>> >>> We speculate the following solution: Given a variable var (whose tree is >>> tree_of_var) and a tree, say t, >>> >>> if (TREE_CODE(t) is MEM_REF) and (TREE_OPERAND(t, 0) is tree_of_var) >>> then >>> the type of the expression inside MEM[...] of tree t is >>> POINTER_TYPE to TREE_TYPE(t). >>> >>> Is is correct? It is general enough? >> >> A MEM_REF has 3 possibly distinct types. If TREE_CODE (t) == MEM_REF, >> one type, TREE_TYPE (t), is the type of the access, struct node * >> in the above case. Another type is one for alias analysis purposes, >> stored in TREE_TYPE (TREE_OPERAND (t, 1)), this one will be >> struct node ** in your case. And yet another type is the type of the >> pointer, TREE_TYPE (TREE_OPERAND (t, 0)), which usually is the same >> as pointer to TREE_TYPE (t) initially, but as most of pointer conversions >> are regarded as useless, after optimization passes you often can end up >> there with very different type. > > > In our case, TREE_TYPE (TREE_OPERAND (t, 0)) as extracted from the tree node > turns out to be "void *" which is same as the original type of the variable > pvar.0. > > From your reply, can I conclude that because of the type cast operation, I > can ignore the TREE_TYPE (TREE_OPERAND (t, 0)) recorded in the tree and > instead take it to be pointer to TREE_TYPE(t)? > >> The type for alias analysis purposes can also differ from pointer to >> TREE_TYPE (t), consider e.g. >>short *p = ...; >>int i = 26; >>memcpy (p, &i, sizeof (int)); >> which is folded (depending on alignment behavior) as MEM_REF[(int *)p] = >> 26; >> and here TREE_TYPE (t) will be int, TREE_TYPE (TREE_OPERAND (t, 0)) likely >> short * and TREE_TYPE (TREE_OPERAND (t, 1)) likely char * (ref_all). > > Here the TREE_TYPE (TREE_OPERAND (t, 0)) suggested by you is consistent with > our observation (here it is "short *" which is same as the original type). > > The question is: can we safely conclude that for the purpose of this > operation (i.e. in this GIMPLE statement), p is being viewed as pointer to > TREE_TYPE(t) which is "int *"? As Jakub said this is not the full story if you factor in type-based aliasing. Also you of course have to account for the offset in operand 1. Richard. > Uday. >
Re: Preserving tree node fields for access in LTO?
On Mon, Jul 27, 2015 at 7:14 PM, Uday Khedker wrote:
>
> We have added a new field (bool ptr_arith in struct tree_base) to the tree
> node. We are assigning values to this field in a gimple pass in non-LTO mode
> and would like to access them in LTO mode in our ipa passes. It appears that
> all fields of tree node are not preserved in LTO mode. Is there any way to
> tell GCC that a given field should be preserved so that it can be accessed
> in LTO mode?
You have to explicitely add the streaming to tree-streamer-{in,out}.c
Richard.
> Thanks and regards,
>
> Uday.
>
>
> Dr. Uday Khedker, Professor
> Department of Computer Science & Engg.
> IIT Bombay, Powai, Mumbai 400 076, India.
> Email : u...@cse.iitb.ac.in
> Homepage:http://www.cse.iitb.ac.in/~uday
> Phone : 91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct)
>
>
[C++ Patch, preapproved] Prefer DECL_SOURCE_LOCATION to "+D" and "+#D" (2/n)
Hi,
other bits. Tested x86_64-linux.
Thanks,
Paolo.
//
2015-07-28 Paolo Carlini
* call.c (build_op_delete_call, convert_like_real, build_over_call):
Use Use DECL_SOURCE_LOCATION and "%qD" in inform and pedwarn instead
of "%q+D".
* constexpr.c (explain_invalid_constexpr_fn): Likewise.
* decl.c (duplicate_decls): Likewise for warning/warning_at.
* except.c (maybe_noexcept_warning): Likewise.
* friend.c (make_friend_class): Likewise for inform.
* mangle.c (mangle_decl): Likewise for warning/warning_at.
* method.c (process_subob_fn, walk_field_subobs,
maybe_explain_implicit_delete): Likewise for inform.
* parser.c (cp_parser_lambda_introducer): Likewise.
* pt.c (check_specialization_namespace,
maybe_process_partial_specialization): Likewise for permerror.
(redeclare_class_template): Likewise for inform_n.
(coerce_template_parms, tsubst_copy_and_build): Likewise for inform.
* search.c (check_final_overrider): Likewise.
* semantics.c (process_outer_var_ref): Likewise.
Index: call.c
===
--- call.c (revision 226260)
+++ call.c (working copy)
@@ -5843,7 +5843,7 @@ build_op_delete_call (enum tree_code code, tree ad
= G_("exception cleanup for this placement new selects "
"non-placement operator delete");
const char *msg2
- = G_("%q+D is a usual (non-placement) deallocation "
+ = G_("%qD is a usual (non-placement) deallocation "
"function in C++14 (or with -fsized-deallocation)");
/* But if the class has an operator delete (void *), then that is
@@ -5865,7 +5865,7 @@ build_op_delete_call (enum tree_code code, tree ad
{
if ((complain & tf_warning)
&& warning (OPT_Wc__14_compat, msg1))
- inform (0, msg2, fn);
+ inform (DECL_SOURCE_LOCATION (fn), msg2, fn);
goto ok;
}
@@ -5875,9 +5875,10 @@ build_op_delete_call (enum tree_code code, tree ad
{
/* Only mention C++14 for namespace-scope delete. */
if (DECL_NAMESPACE_SCOPE_P (fn))
- inform (0, msg2, fn);
+ inform (DECL_SOURCE_LOCATION (fn), msg2, fn);
else
- inform (0, "%q+D is a usual (non-placement) deallocation "
+ inform (DECL_SOURCE_LOCATION (fn),
+ "%qD is a usual (non-placement) deallocation "
"function", fn);
}
}
@@ -6333,8 +6334,8 @@ convert_like_real (conversion *convs, tree expr, t
build_user_type_conversion (totype, convs->u.expr, LOOKUP_NORMAL,
complain);
if (fn)
- inform (input_location, " initializing argument %P of %q+D",
- argnum, fn);
+ inform (DECL_SOURCE_LOCATION (fn),
+ " initializing argument %P of %qD", argnum, fn);
}
return error_mark_node;
@@ -6486,8 +6487,8 @@ convert_like_real (conversion *convs, tree expr, t
gcc_unreachable ();
maybe_print_user_conv_context (convs);
if (fn)
- inform (input_location,
- " initializing argument %P of %q+D", argnum, fn);
+ inform (DECL_SOURCE_LOCATION (fn),
+ " initializing argument %P of %qD", argnum, fn);
return error_mark_node;
}
@@ -7307,7 +7308,8 @@ build_over_call (struct z_candidate *cand, int fla
pedwarn (input_location, 0, "deducing %qT as %qT",
non_reference (TREE_TYPE (patparm)),
non_reference (type));
- pedwarn (input_location, 0, " in call to %q+D", cand->fn);
+ pedwarn (DECL_SOURCE_LOCATION (cand->fn), 0,
+ " in call to %qD", cand->fn);
pedwarn (input_location, 0,
" (you can disable this with -fno-deduce-init-list)");
}
Index: constexpr.c
===
--- constexpr.c (revision 226260)
+++ constexpr.c (working copy)
@@ -829,7 +829,8 @@ explain_invalid_constexpr_fn (tree fun)
save_loc = input_location;
input_location = DECL_SOURCE_LOCATION (fun);
- inform (0, "%q+D is not usable as a constexpr function because:", fun);
+ inform (input_location,
+ "%qD is not usable as a constexpr function because:", fun);
/* First check the declaration. */
if (is_valid_constexpr_fn (fun, true))
{
Index: decl.c
===
--- decl.c (revision 226260)
+++ decl.c (working copy)
@@ -1378,8 +1378,9 @@ duplicate_decls (tree newdec
Re: making the new if-converter not mangle IR that is already vectorizer-friendly
On Tue, Jul 21, 2015 at 10:19 PM, Abe wrote: > First: my apologies for the delay in this reply. Likewise ;) > > [Richard wrote:] >> >> Well, but we do have a pretty strong if-converter on RTL > >> which has access to target specific information. > > Yes, I have had a quick look at it. It looks quite thorough. > > I think I see that you [Richard] are implying that the if converter > at the GIMPLE level should not be trying to do all the if-conversion > work that could possibly be done. I agree with that. However, > AFAIK the RTL work is done strictly after the autovectorization, > so any if conversion that is strictly for the benefit of > autovectorization must be done before autovectorization > and therefor at the GIMPLE level. Corrections are welcome. Yes, the GIMPLE if-converter should strictly be a vectorization enabler. If the "new" if-converter produces code that the vectorizer does not handle (on the target targeted) then it has done a bad job. > > [Abe wrote:] >>> >>> The preceding makes me wonder: has anybody considered adding an >>> optimization >>> profile for GCC, […] that optimizes for the amount of energy consumed? > >>> I don`t remember reading about anything like that […] > > [Richard wrote:] >> >> I think there were GCC summit papers/talks about this. > > > Thanks, but can you please be more specific? > > After writing the message quotes above as "[Abe wrote:]" > I found 2 or 3 papers about compiling code with an eye > towards energy efficiency, but not a whole hell of a lot, > and I didn`t yet find anything GCC-specific on this topic. > > > [Abe wrote:] >>> >>> The old one can, in some cases, produce code that >>> e.g. dereferences a null pointer when the same >>> program given the same inputs would have not > >>> done so without the if-conversion "optimization". > > [Richard wrote:] >> >> Testcase? I don't think it can and if it can this bug needs to be fixed. > > > With the program below my sign-off, using stock GCC 4.9.2, even under "-O3" > the code compiles and runs OK, even when using "-ftree-loop-if-convert", > which is I guess what you [Richard] meant by a recent comment to me [Abe]. > Sebastian confirmed in person that even the old if converter did things > differently > even to loads when GCC is invoked with the full > "-ftree-loop-if-convert-stores" > flag but without "-ftree-loop-if-convert-stores". With the old converter, > compiling with "-ftree-loop-if-convert-stores" yields a program that > segfaults due > to dereferencing a null pointer [it would deref. a _lot_ of them if it > _could_ ;-)]. > > [tested using GCC 4.9.2 on both Cygwin (64-bit) for Windows 7, AMD64 > compilation, > and Mac OS X 10.6.8 -- also using GCC 4.9.2 -- compiling for both ia32 and > AMD64] > > I intend to adapt the test case to DejaGNU format and add > it to the codebase from which the patch is being generated. I think I fixed this bug. It was because of an inverted test. 2015-07-10 Richard Biener PR tree-optimization/66823 * tree-if-conv.c (memrefs_read_or_written_unconditionally): Fix inverted predicate. > > [Abe wrote:] >>> >>> The new converter reduces/eliminates this problem. > > > [Richard wrote:] >> >> You mean the -ftree-loop-if-convert-stores path. > > > The old converter apparently only produced code with the aforementioned > crashing problem only when "-ftree-loop-if-convert-stores" is/was in use, > yes. Due to a bug. It was never supposed to do invalid transforms. It was known to produce store data-races with -ftree-loop-if-convert-stores. That is something the scratchpad use avoids (at the expense of a lot(?) of vectorization). > The new one should not be producing code with that problem > regardless of "-ftree-loop-if-convert-stores" or lack thereof. > > I think the reason for the confusing ambiguity is that since the old > converter > did conversion of stores in a way that was thread-unsafe for half hammocks > [e.g. C source code like "if (condition) A[a] = something;" with no > attached > "else", assuming "condition" and "something" are both conversion-friendly], > somebody used "-ftree-loop-if-convert-stores" to mean "if-convert as much > as possible even if doing so requires converting unsafely". In the new > converter we have no such unsafety TTBOMK, so I propose to remove that flag. First of all to fix regressions on the load if-conversion side you should stop using a scratchpad for loads (do you have one? I seem to remember you do from the design description). load data-races are only theoretical. Then you should IMHO keep the old store path for --param allow-store-data-races=1. I'd like to see a comparison in the number of vectorized loops for SPEC CPU 2006 FP with -Ofast -ftree-loop-if-convert-stores with / without the new if-converter (and if you like also without -ftree-loop-if-convert-stores). You can use -fopt-info-vec and grep for the number of 'loop vectorized' cases. Thanks, Richard. > Regards, > > Abe > > > > > >
Re: Debug assertion and constexpr
On 27/07/15 21:16 +0200, François Dumont wrote: Hello There are at the moment several failures in the libstdc++ testsuite when run in debug mode (_GLIBCXX_DEBUG). This is so because debug assertions are not const expressions. Several debug assertions have been removed because of this issue. So is there a way to define a function as to be ignored in the context of a const expression ? If not could we add one ? No, there is no way without making non-standard front end changes. I think we should wait and see if http://cplusplus.github.io/LWG/lwg-active.html#2234 get resolved, then we can use __builtin_assert() in constexpr functions. It won't give us the full Debug Mode assertion powers, so no pretty messages containing formatted information, but we could still assert.
Re: Preserving tree node fields for access in LTO?
Richard Biener wrote on Tuesday 28 July 2015 01:12 PM:
On Mon, Jul 27, 2015 at 7:14 PM, Uday Khedker wrote:
We have added a new field (bool ptr_arith in struct tree_base) to the tree
node. We are assigning values to this field in a gimple pass in non-LTO mode
and would like to access them in LTO mode in our ipa passes. It appears that
all fields of tree node are not preserved in LTO mode. Is there any way to
tell GCC that a given field should be preserved so that it can be accessed
in LTO mode?
You have to explicitely add the streaming to tree-streamer-{in,out}.c
Thanks for this info. We have done the following:
(a) Added a field to tree_base in the file tree.h as follows:
unsigned ptr_arith : 1;
right after
ENUM_BITFIELD(tree_code) code : 16;
(b) Added the following code to function pack_ts_base_value_fields in the file
tree-streamer-out.c
bp_pack_value (bp, TREE_PTR_ARITH (expr), 1);
just after
bp_pack_value (bp, TREE_CODE (expr), 16);
Macro TREE_PTR_ARITH access the field pts_arith.
(c) Added the following code to function unpack_ts_base_value_fields in the
file tree-streamer-in.c
TREE_PTR_ARITH (expr) = (unsigned) bp_unpack_value (bp, 1);
right in the beginning.
We are getting the correct values in non-LTO mode of our pass. However, the
same code has values 0 in the LTO mode execution.
Is there anything else that we need to do? We briefly looked at the functions
in tree-streamer-{in,out}.c but could not guess if something more needs to be
done
Uday.
Re: Preserving tree node fields for access in LTO?
On July 28, 2015 4:37:15 PM GMT+02:00, "Uday P. Khedker"
wrote:
>
>
>Richard Biener wrote on Tuesday 28 July 2015 01:12 PM:
>> On Mon, Jul 27, 2015 at 7:14 PM, Uday Khedker
>wrote:
>>> We have added a new field (bool ptr_arith in struct tree_base) to
>the tree
>>> node. We are assigning values to this field in a gimple pass in
>non-LTO mode
>>> and would like to access them in LTO mode in our ipa passes. It
>appears that
>>> all fields of tree node are not preserved in LTO mode. Is there any
>way to
>>> tell GCC that a given field should be preserved so that it can be
>accessed
>>> in LTO mode?
>> You have to explicitely add the streaming to tree-streamer-{in,out}.c
>>
>>
>Thanks for this info. We have done the following:
>
>(a) Added a field to tree_base in the file tree.h as follows:
>
> unsigned ptr_arith : 1;
>
> right after
>
> ENUM_BITFIELD(tree_code) code : 16;
>
>(b) Added the following code to function pack_ts_base_value_fields in
>the file tree-streamer-out.c
>
>bp_pack_value (bp, TREE_PTR_ARITH (expr), 1);
>
> just after
>
>bp_pack_value (bp, TREE_CODE (expr), 16);
>
>Macro TREE_PTR_ARITH access the field pts_arith.
>
>(c) Added the following code to function unpack_ts_base_value_fields in
>the file tree-streamer-in.c
>
>TREE_PTR_ARITH (expr) = (unsigned) bp_unpack_value (bp, 1);
>
> right in the beginning.
>
>We are getting the correct values in non-LTO mode of our pass. However,
>the same code has values 0 in the LTO mode execution.
>
>Is there anything else that we need to do? We briefly looked at the
>functions in tree-streamer-{in,out}.c but could not guess if something
>more needs to be done
No, that should be all. Though dependent on what trees the flags are on you
might want to change the tree compare function in lto.c as well.
Are you sure the trees survive until lto streaming?
Richard.
>Uday.
Expectations for 0/0
Hi,
What are the expectations for the 0/0 division?
Test execute.exp=arith-rand.c generates two integers, both being 0 and one of
the testing blocks is:
{ signed int xx = x, yy = y, r1, r2;
if ((unsigned int) xx << 1 == 0 && yy == -1)
continue;
r1 = xx / yy;
r2 = xx % yy;
if (ABS (r2) >= (unsigned int) ABS (yy) || (signed int) (r1 * yy + r2)
!= xx)
abort ();
}
Our routine returns :
R1: 0x
R2: 0xf
Then it aborts because ABS (r2) >= (unsigned int) ABS (yy).
While I understand the results from our division routine might be peculiar,
this division is also undefined.
The block skips the test for ((unsigned int) xx << 1 == 0 && yy == -1), should
we skip it if they're both zero as well? If not, what do you expect to get from
0/0 and 0%0?
Regards,
Paulo Matos
Re: Preserving tree node fields for access in LTO?
On 07/28/2015 08:10 PM, Richard Biener wrote:
On July 28, 2015 4:37:15 PM GMT+02:00, "Uday P. Khedker"
wrote:
Richard Biener wrote on Tuesday 28 July 2015 01:12 PM:
On Mon, Jul 27, 2015 at 7:14 PM, Uday Khedker
wrote:
We have added a new field (bool ptr_arith in struct tree_base) to
the tree
node. We are assigning values to this field in a gimple pass in
non-LTO mode
and would like to access them in LTO mode in our ipa passes. It
appears that
all fields of tree node are not preserved in LTO mode. Is there any
way to
tell GCC that a given field should be preserved so that it can be
accessed
in LTO mode?
You have to explicitely add the streaming to tree-streamer-{in,out}.c
Thanks for this info. We have done the following:
(a) Added a field to tree_base in the file tree.h as follows:
unsigned ptr_arith : 1;
right after
ENUM_BITFIELD(tree_code) code : 16;
(b) Added the following code to function pack_ts_base_value_fields in
the file tree-streamer-out.c
bp_pack_value (bp, TREE_PTR_ARITH (expr), 1);
just after
bp_pack_value (bp, TREE_CODE (expr), 16);
Macro TREE_PTR_ARITH access the field pts_arith.
(c) Added the following code to function unpack_ts_base_value_fields in
the file tree-streamer-in.c
TREE_PTR_ARITH (expr) = (unsigned) bp_unpack_value (bp, 1);
right in the beginning.
We are getting the correct values in non-LTO mode of our pass. However,
the same code has values 0 in the LTO mode execution.
Is there anything else that we need to do? We briefly looked at the
functions in tree-streamer-{in,out}.c but could not guess if something
more needs to be done
No, that should be all. Though dependent on what trees the flags are on you
might want to change the tree compare function in lto.c as well.
Are you sure the trees survive until lto streaming?
The trees survive because all other fields show correct values. Only the
new flag remains 0.
Our flag is present in the tree unconditionally. We have written a pass
which sets this flag conditionally for a tree that involves a pointer
arithmetic (default value is 0).
Which comparison function are you referring to? There is a function
lto_splay_tree_compare_ids in lto.c. Is there any other function that we
are missing?
If it matters: We are using gcc-4.7.2 and using the option
-flto-partition=none.
Uday.
Re: Expectations for 0/0
On 07/28/2015 04:40 PM, Paulo Matos wrote: > The block skips the test for ((unsigned int) xx << 1 == 0 && yy == -1), > should we skip it if they're both zero as well? Yes. It's undefined behaviour. If we don't want to invoke nasal daemons we shouldn't do this. Andrew.
Re: Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 21/04/15 06:27, Jeff Law wrote: On 04/20/2015 01:09 AM, Shiva Chen wrote: Hi, Jeff Thanks for your advice. can_replace_by.patch is the new patch to handle both cases. pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump after patch can_replace_by.patch Could you help me to review the patch? Thanks. This looks pretty good. I expanded the comment for the new function a bit and renamed the function in an effort to clarify its purpose. From reviewing can_replace_by, it seems it should have been handling this case, but clearly wasn't due to implementation details. I then bootstrapped and regression tested the patch on x86_64-linux-gnu where it passed. I also instrumented that compiler to see how often this code triggers. During a bootstrap it triggers a couple hundred times (which is obviously a proxy for cross jumping improvements). So it's triggering regularly on x86_64, which is good. I also verified that this fixes BZ64916 for an arm-non-eabi toolchain configured with --with-arch=armv7. Installed on the trunk. No new testcase as it's covered by existing tests. Thanks,, jeff Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? Kind regards, Alex
gcc-5-20150728 is now available
Snapshot gcc-5-20150728 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150728/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 226331 You'll find: gcc-5-20150728.tar.bz2 Complete GCC MD5=ceea4f29afc143ebf9e0dc1d874e4097 SHA1=62cd27d674101aa43520dc51e58b4294abe29917 Diffs from 5-20150721 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
