Re: New dump infrastructure
A more simpler use model is not to guard the dump statement at all -- just express the intention a) what to dump; b) as what kind or to where 1) I want to dump the something as optimized message: dump_printf (MSG_OPTIMIZED, "blah...") dump_printf_loc (MSG_OPTIMIZED, "blah") 2) I want to dump something together with tree dump regardless of the flag: dump_printf (TDF_TREE, ...); 3) I want to dump something with tree dump when detailed flags is set: dump_printf (TDF_DETAILS, ...); The dumping code is not in the critical path, so the compile time should not be a concern. David On Tue, Oct 16, 2012 at 11:42 PM, Sharad Singhai wrote: >> 1. OK, I understand that e.g. >> >> if (dump_file && (dump_flags & TDF_DETAILS)) >> >>should be converted into: >> >> if (dump_kind_p (TDF_DETAILS)) >> >>But what about current code that does not care about dump_flags? >>E.g. converting simple >> >> if (dump_file) >> >>to >> >> if (dump_kind_p (0)) >> >>won't work, dump_kind_p will always return zero in such cases. > > > Yes, you are right, the conversion is not completely mechanical and > some care must be taken to preserve the original intent. I think one > of the following might work in the case where a pass doesn't care > about the dump_flags > > 1. use generic pass type flags, such as TDF_TREE, TDF_IPA, TDF_RTL > which are guaranteed to be set depending on the pass type, > 2. this dump statement might be a better fit for MSG_* flags if it > deals with optimizations. Sometimes "if (dump_file) fpritnf > (dump_file, ...)" idiom was used for these situations and now these > sites might be perfect candidate for converting into MSG_* flags. > > If a cleaner way to handle this is desired, perhaps we can add an > unconditional "dump_printf_always (...)", but currently it seems > unnecessary. Note that for optimization messages which should always > be printed, one can use MSG_ALL flag. However, no analogous flag > exists for regular dumps. How about adding a corresponding TDF_ALL > flag? Would that work? > >> >> >> 2. dump_kind_p seems to always return 0 if current_function_decl is >>NULL. However, that precludes its use in IPA passes in which this >>can happen regularly. Why is this restriction necessary? > > > This is an oversight on my part. Originally, I wanted to be able to > print source location information and this is a remnant of that. I am > testing a patch to fix that. > > Thanks, > Sharad
Re: How to add pass filtering for -fopt-info
> I don't like B), it is unlike everything else a pass does. You seem to > use the new field to indicate a group - that makes it a flat hierarchy > which might make it limiting (for example 'vect' may include both loop > and scalar vectorization, but would 'loop' also include loop vectorization?). > Using a bitmask and an enum would be my preference for this reason > (similar to how we have TDF_ flags). Loop vectorization would then > be vect|loop for example. Yes, I was thinking of groups of optimizations as a single high-level name. But I agree that it is an unnecessary restriction. I will work towards a set of flags instead. Also, another kind of grouping is possible via sub-passes in certain cases. For example, "loop2" or "early_optimizations" could imply sub-passes. Not sure how useful that would be. Thanks, Sharad
When is char_type_node available in plugins?
Hello All,
While coding (in MELT)
https://github.com/bstarynk/melt-examples/tree/master/ex06
(which is essentially a MELT extension using the MELT 0.9.7 plugin from
http://gcc-melt.org/ )
I noticed that the char_type_node tree from gcc/tree.h is not available
(i.e. is still NULL) when the plugin_init function of a plugin is called.
Perhaps we should add a comment in gcc/tree.h explaining that, and state more
precisely when is char_type_node really usable.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: New dump infrastructure
On Wed, Oct 17, 2012 at 9:05 AM, Xinliang David Li wrote:
> A more simpler use model is not to guard the dump statement at all --
> just express the intention a) what to dump; b) as what kind or to
> where
>
>
> 1) I want to dump the something as optimized message:
>
> dump_printf (MSG_OPTIMIZED, "blah...")
>
> dump_printf_loc (MSG_OPTIMIZED, "blah")
>
> 2) I want to dump something together with tree dump regardless of the flag:
>
>dump_printf (TDF_TREE, ...);
>
> 3) I want to dump something with tree dump when detailed flags is set:
>
> dump_printf (TDF_DETAILS, ...);
>
>
> The dumping code is not in the critical path, so the compile time
> should not be a concern.
That's not true in all cases which is why I asked for the predicate to be
available, especially for the case where it guards multiple dump_* statement.
Look for example at CCPs ccp_visit_stmt which calls
if (dump_file && (dump_flags & TDF_DETAILS))
{
fprintf (dump_file, "\nVisiting statement:\n");
print_gimple_stmt (dump_file, stmt, 0, dump_flags);
}
and ends up calling evaluate_stmt most of the time:
if (dump_file && (dump_flags & TDF_DETAILS))
{
fprintf (dump_file, "which is likely ");
switch (likelyvalue)
{
case CONSTANT:
fprintf (dump_file, "CONSTANT");
break;
case UNDEFINED:
fprintf (dump_file, "UNDEFINED");
break;
case VARYING:
fprintf (dump_file, "VARYING");
break;
default:;
}
fprintf (dump_file, "\n");
}
such code is not something you'd want to do unconditionally.
I agree the use of the predicate can be reduced in some cases but it has
to be available for cases like the above. And eventually have a fast-path
inlined like
inline bool dump_kind_p (int flags)
{
return any_dump_enabled_p ? dump_kind_p_1 (flags) : false;
}
or a new inline function
inline bool dump_enabled_p ()
{
return any_dump_enabled_p;
}
at the cost of one extra global flag we'd need to maintain. Probably the
latter would be what you prefer? That way we don't get redundant
or even conflicting flags on the predicate check vs. the dump stmts.
Thanks,
Richard.
> David
>
>
> On Tue, Oct 16, 2012 at 11:42 PM, Sharad Singhai wrote:
>>> 1. OK, I understand that e.g.
>>>
>>> if (dump_file && (dump_flags & TDF_DETAILS))
>>>
>>>should be converted into:
>>>
>>> if (dump_kind_p (TDF_DETAILS))
>>>
>>>But what about current code that does not care about dump_flags?
>>>E.g. converting simple
>>>
>>> if (dump_file)
>>>
>>>to
>>>
>>> if (dump_kind_p (0))
>>>
>>>won't work, dump_kind_p will always return zero in such cases.
>>
>>
>> Yes, you are right, the conversion is not completely mechanical and
>> some care must be taken to preserve the original intent. I think one
>> of the following might work in the case where a pass doesn't care
>> about the dump_flags
>>
>> 1. use generic pass type flags, such as TDF_TREE, TDF_IPA, TDF_RTL
>> which are guaranteed to be set depending on the pass type,
>> 2. this dump statement might be a better fit for MSG_* flags if it
>> deals with optimizations. Sometimes "if (dump_file) fpritnf
>> (dump_file, ...)" idiom was used for these situations and now these
>> sites might be perfect candidate for converting into MSG_* flags.
>>
>> If a cleaner way to handle this is desired, perhaps we can add an
>> unconditional "dump_printf_always (...)", but currently it seems
>> unnecessary. Note that for optimization messages which should always
>> be printed, one can use MSG_ALL flag. However, no analogous flag
>> exists for regular dumps. How about adding a corresponding TDF_ALL
>> flag? Would that work?
>>
>>>
>>>
>>> 2. dump_kind_p seems to always return 0 if current_function_decl is
>>>NULL. However, that precludes its use in IPA passes in which this
>>>can happen regularly. Why is this restriction necessary?
>>
>>
>> This is an oversight on my part. Originally, I wanted to be able to
>> print source location information and this is a remnant of that. I am
>> testing a patch to fix that.
>>
>> Thanks,
>> Sharad
Re: How to add pass filtering for -fopt-info
On Wed, Oct 17, 2012 at 9:32 AM, Sharad Singhai wrote: >> I don't like B), it is unlike everything else a pass does. You seem to >> use the new field to indicate a group - that makes it a flat hierarchy >> which might make it limiting (for example 'vect' may include both loop >> and scalar vectorization, but would 'loop' also include loop vectorization?). >> Using a bitmask and an enum would be my preference for this reason >> (similar to how we have TDF_ flags). Loop vectorization would then >> be vect|loop for example. > > Yes, I was thinking of groups of optimizations as a single high-level > name. But I agree that it is an unnecessary restriction. I will work > towards a set of flags instead. > > Also, another kind of grouping is possible via sub-passes in certain > cases. For example, "loop2" or "early_optimizations" could imply > sub-passes. Not sure how useful that would be. They are mostly implementation details, so I doubt it is useful to collect information from "parent" passes. Richard. > > Thanks, > Sharad
Re: When is char_type_node available in plugins?
On Wed, Oct 17, 2012 at 11:02 AM, Basile Starynkevitch
wrote:
>
> Hello All,
>
> While coding (in MELT)
> https://github.com/bstarynk/melt-examples/tree/master/ex06
> (which is essentially a MELT extension using the MELT 0.9.7 plugin from
> http://gcc-melt.org/ )
> I noticed that the char_type_node tree from gcc/tree.h is not available
> (i.e. is still NULL) when the plugin_init function of a plugin is called.
>
> Perhaps we should add a comment in gcc/tree.h explaining that, and state more
> precisely when is char_type_node really usable.
No, we should document that in plugin_init the plugin may not expect
anything from the GCC side apart from the plugin.h API, thus should only perform
init things. Which looks obvious from the name of the hook.
Richard.
> Regards.
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
Re: RFD: HAVE_* pattern flags
On Tue, 16 Oct 2012, Joern Rennecke wrote: > - Change the semantics of the HAVE_pattern macros for officially named >patterns so that they are defined as 0 when the pattern is not provided? >That choice would actually force people to change #ifdef into if (), >without the possibility of #if, where targets can have non-constant >pattern predicates. I think that's appropriate. Note: for patterns that involve a machine mode, I think it's better to generate a macro (or function) that takes the mode as a parameter. This is because most references to modes such as SImode or DFmode in architecture-independent code are in principle dubious and would need to be eliminated for ports to unusual architectures with non-8-bit bytes (rather than being defined in architecture-independent code, it would be better to have a config/8-bit-byte-modes.def that's used by normal architectures but not by any future unusual ones). For example, if such macros / functions are generated automatically, c-family/c-cppbuiltin.c:mode_has_fma could cease to hardcode a list of four floating-point modes; instead, the caller could just call the new HAVE_ macro directly, with the mode as a parameter. > - We could have a header file that is maintained by hand, with a string >of #ifdef / #define / #endif . I think this is probably the simplest and so best approach - just list those patterns for which the HAVE_* is actually used. Or a text file with a list, indicating in some way the machine mode parameters to patterns for which those are relevant. -- Joseph S. Myers jos...@codesourcery.com
Re: New dump infrastructure
On Wed, Oct 17, 2012 at 2:08 AM, Richard Biener
wrote:
> On Wed, Oct 17, 2012 at 9:05 AM, Xinliang David Li wrote:
>> A more simpler use model is not to guard the dump statement at all --
>> just express the intention a) what to dump; b) as what kind or to
>> where
>>
>>
>> 1) I want to dump the something as optimized message:
>>
>> dump_printf (MSG_OPTIMIZED, "blah...")
>>
>> dump_printf_loc (MSG_OPTIMIZED, "blah")
>>
>> 2) I want to dump something together with tree dump regardless of the flag:
>>
>>dump_printf (TDF_TREE, ...);
>>
>> 3) I want to dump something with tree dump when detailed flags is set:
>>
>> dump_printf (TDF_DETAILS, ...);
>>
>>
>> The dumping code is not in the critical path, so the compile time
>> should not be a concern.
>
> That's not true in all cases which is why I asked for the predicate to be
> available, especially for the case where it guards multiple dump_* statement.
>
> Look for example at CCPs ccp_visit_stmt which calls
>
> if (dump_file && (dump_flags & TDF_DETAILS))
> {
> fprintf (dump_file, "\nVisiting statement:\n");
> print_gimple_stmt (dump_file, stmt, 0, dump_flags);
> }
>
Yes -- that means guarding is for performance reason and can be made optional.
> and ends up calling evaluate_stmt most of the time:
That looks too expensive even with the guard. Can it be turned off in
non debug build?
>
> if (dump_file && (dump_flags & TDF_DETAILS))
> {
> fprintf (dump_file, "which is likely ");
> switch (likelyvalue)
> {
> case CONSTANT:
> fprintf (dump_file, "CONSTANT");
> break;
> case UNDEFINED:
> fprintf (dump_file, "UNDEFINED");
> break;
> case VARYING:
> fprintf (dump_file, "VARYING");
> break;
> default:;
> }
> fprintf (dump_file, "\n");
> }
>
> such code is not something you'd want to do unconditionally.
>
ok.
> I agree the use of the predicate can be reduced in some cases but it has
> to be available for cases like the above. And eventually have a fast-path
> inlined like
>
> inline bool dump_kind_p (int flags)
> {
> return any_dump_enabled_p ? dump_kind_p_1 (flags) : false;
> }
>
> or a new inline function
>
> inline bool dump_enabled_p ()
> {
> return any_dump_enabled_p;
> }
>
> at the cost of one extra global flag we'd need to maintain. Probably the
> latter would be what you prefer? That way we don't get redundant
> or even conflicting flags on the predicate check vs. the dump stmts.
>
Another way:
To make the dumping code as concise as possible, we can make
dump_printf a inlinable wrapper:
inline void dump_printf (...)
{
if (!any_dump_enabled_p)
return;
// regular stuff
}
thanks,
David
> Thanks,
> Richard.
>
>> David
>>
>>
>> On Tue, Oct 16, 2012 at 11:42 PM, Sharad Singhai wrote:
1. OK, I understand that e.g.
if (dump_file && (dump_flags & TDF_DETAILS))
should be converted into:
if (dump_kind_p (TDF_DETAILS))
But what about current code that does not care about dump_flags?
E.g. converting simple
if (dump_file)
to
if (dump_kind_p (0))
won't work, dump_kind_p will always return zero in such cases.
>>>
>>>
>>> Yes, you are right, the conversion is not completely mechanical and
>>> some care must be taken to preserve the original intent. I think one
>>> of the following might work in the case where a pass doesn't care
>>> about the dump_flags
>>>
>>> 1. use generic pass type flags, such as TDF_TREE, TDF_IPA, TDF_RTL
>>> which are guaranteed to be set depending on the pass type,
>>> 2. this dump statement might be a better fit for MSG_* flags if it
>>> deals with optimizations. Sometimes "if (dump_file) fpritnf
>>> (dump_file, ...)" idiom was used for these situations and now these
>>> sites might be perfect candidate for converting into MSG_* flags.
>>>
>>> If a cleaner way to handle this is desired, perhaps we can add an
>>> unconditional "dump_printf_always (...)", but currently it seems
>>> unnecessary. Note that for optimization messages which should always
>>> be printed, one can use MSG_ALL flag. However, no analogous flag
>>> exists for regular dumps. How about adding a corresponding TDF_ALL
>>> flag? Would that work?
>>>
2. dump_kind_p seems to always return 0 if current_function_decl is
NULL. However, that precludes its use in IPA passes in which this
can happen regularly. Why is this restriction necessary?
>>>
>>>
>>> This is an oversight on my part. Originally, I wanted to be able to
>>> print source location information and this is a remnant of that. I am
>>> testing a patch to fix that.
>>>
>>> Thanks,
>>> Sharad
Re: RFD: HAVE_* pattern flags
On 2012-10-17 10:31, Joern Rennecke wrote: > - What would a good naming scheme be? > - Change the semantics of the HAVE_pattern macros for officially named > patterns so that they are defined as 0 when the pattern is not provided? > That choice would actually force people to change #ifdef into if (), > without the possibility of #if, where targets can have non-constant > pattern predicates. I'm preferential for this, because that's what I've tended to sprinkle across the sources as needed when writing new code: #ifndef HAVE_foo # define HAVE_foo 0 # define gen_foo(x,y,z) (gcc_unreachable(), NULL_RTX) #endif > - Have_pattern? > - have_pattern? > - any other preferences? I don't see any reason to stray from HAVE_pattern. > - how do we get the list of 'official' named patterns? > - We could have a header file that is maintained by hand, with a string > of #ifdef / #define / #endif . This could be trivially integrated with genopinit and optabs.def, if we cared to do so. I'm not committed to that idea though. r~
Re: New dump infrastructure
On Tue, Oct 16, 2012 at 11:17 PM, Georg-Johann Lay wrote:
> How are dumps from the backend handled then?
I haven't really looked at backends. Perhaps they can be converted at
the cost of extra dispatch functions defined in dumpfile.c. For
example, we can add methods like 'dump_rtl_single ()' and
'dump_inline_rtx ()' to the dump interface.
> For example, SPU uses fprintf to dump_file.
These call sites should be easier to handle. For example, the
following fragment from config/spu/spu.c:spu_sms_res_mii
if (dump_file && INSN_P (insn))
fprintf (dump_file, "i%d %s %d %d\n",
INSN_UID (insn),
insn_data[INSN_CODE(insn)].name,
p, t[p]);
can be rewritten as
if (dump_kind_p (TDF_RTL) && INSN_P (insn))
dump_printf ("i%d %s %d %d\n",
INSN_UID (insn),
insn_data[INSN_CODE(insn)].name,
p, t[p]);
>
> A backend can easily add additional information to dump files by using printf
> or putc or print_inline_rtx or implement whatever own %-codes to neatly print
> information.
Not all of the use cases you mention need to be converted. I was
rather more interested in distilling high-level optimizations.
However, I suspect even in the backends, some sites might benefit by
converting them into -fopt-info format.
> How will that work after the old interface has been deprecated?
> Will there be %-Hooks similar to targetm.print_operand?
The dump_file is not going away, only the way to access it would change.
Thanks,
Sharad
>
> Johann
>
Re: RFD: HAVE_* pattern flags
On 2012-10-18 00:39, Joseph S. Myers wrote: > Note: for patterns that involve a machine mode, I think it's better to > generate a macro (or function) that takes the mode as a parameter. This > is because most references to modes such as SImode or DFmode in > architecture-independent code are in principle dubious and would need to > be eliminated for ports to unusual architectures with non-8-bit bytes > (rather than being defined in architecture-independent code, it would be > better to have a config/8-bit-byte-modes.def that's used by normal > architectures but not by any future unusual ones). > > For example, if such macros / functions are generated automatically, > c-family/c-cppbuiltin.c:mode_has_fma could cease to hardcode a list of > four floating-point modes; instead, the caller could just call the new > HAVE_ macro directly, with the mode as a parameter. Err... that's exactly what optabs are for. If we need to change when the optabs are initialized to make -save-temps work, then that will be better than any other solution you may be considering. This may be easier since the August rewrite of genopinit.c. r~
Re: New dump infrastructure
On Wed, Oct 17, 2012 at 1:40 PM, Sharad Singhai wrote:
> On Tue, Oct 16, 2012 at 11:17 PM, Georg-Johann Lay wrote:
>
>> How are dumps from the backend handled then?
>
> I haven't really looked at backends. Perhaps they can be converted at
> the cost of extra dispatch functions defined in dumpfile.c. For
> example, we can add methods like 'dump_rtl_single ()' and
> 'dump_inline_rtx ()' to the dump interface.
>
>> For example, SPU uses fprintf to dump_file.
>
> These call sites should be easier to handle. For example, the
> following fragment from config/spu/spu.c:spu_sms_res_mii
>
> if (dump_file && INSN_P (insn))
> fprintf (dump_file, "i%d %s %d %d\n",
> INSN_UID (insn),
> insn_data[INSN_CODE(insn)].name,
> p, t[p]);
>
> can be rewritten as
>
> if (dump_kind_p (TDF_RTL) && INSN_P (insn))
>dump_printf ("i%d %s %d %d\n",
> INSN_UID (insn),
> insn_data[INSN_CODE(insn)].name,
> p, t[p]);
>
>>
>> A backend can easily add additional information to dump files by using
>> printf or putc or print_inline_rtx or implement whatever own %-codes to
>> neatly print information.
>
> Not all of the use cases you mention need to be converted. I was
> rather more interested in distilling high-level optimizations.
> However, I suspect even in the backends, some sites might benefit by
> converting them into -fopt-info format.
>
>> How will that work after the old interface has been deprecated?
>> Will there be %-Hooks similar to targetm.print_operand?
>
> The dump_file is not going away, only the way to access it would change.
>
After all the conversion is done, 'dump_file' should go away (by hiding it).
David
> Thanks,
> Sharad
>
>>
>> Johann
>>
Re: RFD: HAVE_* pattern flags
On 2012-10-17 10:31, Joern Rennecke wrote: > - What would a good naming scheme be? > - Change the semantics of the HAVE_pattern macros for officially named > patterns so that they are defined as 0 when the pattern is not provided? > That choice would actually force people to change #ifdef into if (), > without the possibility of #if, where targets can have non-constant > pattern predicates. I'm preferential for this, because that's what I've tended to sprinkle across the sources as needed when writing new code: #ifndef HAVE_foo # define HAVE_foo 0 # define gen_foo(x,y,z) (gcc_unreachable(), NULL_RTX) #endif > - Have_pattern? > - have_pattern? > - any other preferences? I don't see any reason to stray from HAVE_pattern. > - how do we get the list of 'official' named patterns? > - We could have a header file that is maintained by hand, with a string > of #ifdef / #define / #endif . This could be trivially integrated with genopinit and optabs.def, if we cared to do so. I'm not committed to that idea though. r~
Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0
On Saturday 13 October 2012 02:34 AM, Xinliang David Li wrote: Somewhere it is mentioned that heap is handled conservatively. Does it mean the algorithm can not disambiguate heap objects all all, or it can but does not track pointer values stored in heap objects? How about field sensitivity? For many programs (mostly C++ ones), this is very important. For CS, virtual calls in C++ will be one of the the biggest challenges. How is that dealt with? It can be combined with type propagation/analysis. thanks, David My apologies for the delay. I wanted to check some details with the original implementor Prashant who had his exams. Here's my final response. - In our earlier version, we represented heap locations in terms of base and offset pairs and all locations allocated at the same pointed were treated alike. We used pointer arithmetic to map offset calculation to find out which heap locations can possibly coincide. Where we could not determine unambiguously, we assumed that the location could coincide with any other location. - For non-heap structures (allocated on stack or static area), our analysis is completely field sensitive. - In our updated implementation, we have removed offsets completely for simplicity and made the implementation more conservative. This was primarily to simplify the implementation and gain some efficiency. But a bigger reason is that we have a much better technique of heap analysis in the pipeline. It essentially uses the same abstract idea of restricting pointer information to live data but would use heap liveness analysis [Khedker-Sanyal-Karkare, TOPLAS 2007]. This analysis discovers accesses in deep heap through a data flow analysis that represents the this data flow information flow sensitively in the form of graphs rooted at stack variables. - We handle calls through function pointers by adjusting the call graph as and when we get pointees of the function pointers. In case of a function pointer fptr, we see what fptr may point to, and consider all those functions called from that point. We haven't looked at GCC's IR for a C++ program with virtual functions. But maybe we can store the type of the classes pointed to by an object during the pointer analysis to determine the appropriate function that needs to be invoked. Thanks and regards, Uday.
