Re: A visualization of GCC's passes, as a subway map
On Wed, Jul 13, 2011 at 3:15 PM, Paolo Bonzini wrote: > On 07/13/2011 12:54 PM, Richard Guenther wrote: >> >> > Yes, PROP_gimple_lcx needs to be added to PROP_trees. I cannot approve >> > the >> > patch, unfortunately. >> >> Hm, why? complex operations are lowered after a complex lowering pass >> has executed. they are still lowered on RTL, so I don't see why we need >> to destroy them technically. > > Because it's PROP_*gimple*_lcx. :) Shouldn't it then be PROP_*gimple* instead of PROP_*trees*? ;) We should drop all PROP_trees after gimplification it seems ;) Richard. > Paolo >
Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
On Wed, Jul 13, 2011 at 5:16 PM, Ian Lance Taylor wrote: > Tobias Burnus writes: > >> In that sense, I do not seem to need a new flags for >> asynchronous/coarrays - which are handled by TYPE_QUAL_RESTRICT, but I >> need a new flag for normal (noncoarray, nonasychronous) variables, >> which are passed by value or are allocatable - and where a function >> call won't affect the value. > > Yes, sounds like it. At first glance I don't think it should be a > TYPE_QUAL, I think it should be a flag on the DECL. The issue is that it needs to work for pointer targets - and we don't have a decl for that anonymous thing. The closest we have is middle-end support for restrict qualified pointers which of course cannot capture all of the Fortran semantics, but they can at least capture some. That Fortran passes everything by reference is really really not helping optimizers. It's also not helping that my Fortran FU is weak so I'm not able to produce testcases that will immediately show issues with (proposed) middle-end representations. Richard. > Ian >
Re: A visualization of GCC's passes, as a subway map
On 07/14/2011 11:11 AM, Richard Guenther wrote: >> Hm, why? complex operations are lowered after a complex lowering pass >> has executed. they are still lowered on RTL, so I don't see why we need >> to destroy them technically. > > Because it's PROP_*gimple*_lcx.:) Shouldn't it then be PROP_*gimple* instead of PROP_*trees*?;) Heh, you have a point! Paolo
Ada boolean type
Hi, I'm wondering why for Ada boolean_true_node has a value that is not in the range of the Ada type but is, for the specific case, 255 instead of 1. Is there a specific reason for that? Does the following patch make sense (untested)? Btw, I wonder if Ada cannot simply use its own boolean_type_node global tree and leave the middle-ends boolean_type_node alone, which is supposed to match the C ABI of the target. Thanks, Richard. Index: gcc/ada/gcc-interface/misc.c === --- gcc/ada/gcc-interface/misc.c(revision 176266) +++ gcc/ada/gcc-interface/misc.c(working copy) @@ -323,7 +323,7 @@ gnat_init (void) SET_TYPE_RM_MAX_VALUE (boolean_type_node, build_int_cst (boolean_type_node, 1)); SET_TYPE_RM_SIZE (boolean_type_node, bitsize_int (1)); - boolean_true_node = TYPE_MAX_VALUE (boolean_type_node); + boolean_true_node = TYPE_RM_MAX_VALUE (boolean_type_node); boolean_false_node = TYPE_MIN_VALUE (boolean_type_node); sbitsize_one_node = sbitsize_int (1);
Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
On 07/14/2011 11:21 AM, Richard Guenther wrote:
That Fortran passes everything by reference is really really not helping
optimizers.
I think it also does not harm optimizers. The problem is just that
optimizers are not tuned for it - but for C with later (C99?) attached
qualifiers.
Whether one has
int func(int arg) {
do_something_with_arg
return arg;
}
or
subroutine func(arg) ! arg passed by reference
integer :: arg
shouldn't make any difference for optimizers. The value can only change
by either directly modifying "arg" or by calling a procedure with it as
explicit actual argument, which modifies it.
In Fortran, any tricks like modifying "arg" via a global variable (which
shares the memory location with "arg") are invalid. It is not even
allowed to read the value of the global variable (having the same memory
address as "arg"), if the value of "arg" is modified in "func" - not
even before it is modified.
If one wants to play those tricks, "arg" needs to have at least the
TARGET attribute (i.e. some pointer may point to it) - or even the
POINTER attribute, for which nearly anything goes.
Some of the restrictions are compile-time checkable, i.e. if you try to
pass a non-target, non-pointer variable as actual argument to a
pointer-dummy argument, you will get a compile-time error.
For others, it's the users responsibility. For instance, you may pass a
non-TARGET variable to a function taking a TARGET as dummy argument, but
as soon as that function returns, all pointers to the dummy become
undefined.
The advantage of Fortran is that it not only applies to basic types like
"int" but also to character strings, arrays - and to "allocatables".
Allocatables have to be allocated before one can use them, allowing one
to change the array size or (for deferred-length strings) the string
length. Still, they share the same semantics, i.e. no aliasing unless
there is TARGET or (for non-ALLOCATABLEs) a POINTER attribute.
(Side remark: allocatables [unless SAVE, i.e. in static memory] are
automatically freed, when one leaves their "scoping unit", e.g. for a
variable local to a function, when one leaves that function. That's
Fortran's way of garbage collection. If one does not want it, one has to
use pointers.)
In that sense, the lack of a qualifier in C, which matches Fortran, is
"really really not helping optimizers". ;-)
It's also not helping that my Fortran FU is weak
so I'm not able to produce testcases that will immediately show
issues with (proposed) middle-end representations.
Yes, that's indeed a problem, though I don't see how one can best solve
it. I can only offer to help with questions, finding the relevant
sections in the standard, and helping to interpret them.
For what it is worth, in the Fortran 2008 standard, one finds regarding
this issue (cf. PR 49733) more at:
* "12.5.2.13 Restrictions on entities associated with dummy arguments"
Namely, rules when a dummy argument may be changed behind the scenes,
including when the standard guarantees that the actual and the dummy
argument actually point to the same memory.
That also forbids that one passes twice the same variable as actual
argument, if one modifies either argument. (Unless one has a pointer -
or a TARGET (+ some additional restrictions).)
The additional restrictions are there to avoid issues, when
copy-in/copy-out happens. In some cases Fortran has to make a copy - and
pass the copy instead of the (address of the) actual argument, e.g. if
the dummy argument wants to have a contiguous array but the actual
argument has strides.
* "16.5.2.5 Events that cause the association status of pointers to
become undefined"
For instance, the issue mentioned above: One has a pointer to some
object which has locally a target attribute - or exists only locally -
then the pointer becomes undefined, if one returns from that function.
There are some more relevant spots in the standard, e.g. those where
pointer and target is defined. Or the place, where argument passing is
handled, cf. "12.5.2 Actual arguments, dummy arguments, and argument
association".
For instance an actual argument may only passed to a pointer dummy
argument, if it is a pointer - or if the dummy argument has the target
attribute and the dummy argument is INTENT(IN); the first avoids alias
issues and the second ensures that one does not modify the memory
address to which the argument points to. Cf. "12.5.2.7 Pointer dummy
variables" for the latter.
Tobias
Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
On Thu, Jul 14, 2011 at 12:29 PM, Tobias Burnus wrote:
> On 07/14/2011 11:21 AM, Richard Guenther wrote:
>>
>> That Fortran passes everything by reference is really really not helping
>> optimizers.
>
> I think it also does not harm optimizers. The problem is just that
> optimizers are not tuned for it - but for C with later (C99?) attached
> qualifiers.
>
> Whether one has
> int func(int arg) {
> do_something_with_arg
> return arg;
> }
> or
> subroutine func(arg) ! arg passed by reference
> integer :: arg
>
> shouldn't make any difference for optimizers. The value can only change by
> either directly modifying "arg" or by calling a procedure with it as
> explicit actual argument, which modifies it.
>
> In Fortran, any tricks like modifying "arg" via a global variable (which
> shares the memory location with "arg") are invalid. It is not even allowed
> to read the value of the global variable (having the same memory address as
> "arg"), if the value of "arg" is modified in "func" - not even before it is
> modified.
>
> If one wants to play those tricks, "arg" needs to have at least the TARGET
> attribute (i.e. some pointer may point to it) - or even the POINTER
> attribute, for which nearly anything goes.
>
> Some of the restrictions are compile-time checkable, i.e. if you try to pass
> a non-target, non-pointer variable as actual argument to a pointer-dummy
> argument, you will get a compile-time error.
>
> For others, it's the users responsibility. For instance, you may pass a
> non-TARGET variable to a function taking a TARGET as dummy argument, but as
> soon as that function returns, all pointers to the dummy become undefined.
>
> The advantage of Fortran is that it not only applies to basic types like
> "int" but also to character strings, arrays - and to "allocatables".
> Allocatables have to be allocated before one can use them, allowing one to
> change the array size or (for deferred-length strings) the string length.
> Still, they share the same semantics, i.e. no aliasing unless there is
> TARGET or (for non-ALLOCATABLEs) a POINTER attribute.
>
> (Side remark: allocatables [unless SAVE, i.e. in static memory] are
> automatically freed, when one leaves their "scoping unit", e.g. for a
> variable local to a function, when one leaves that function. That's
> Fortran's way of garbage collection. If one does not want it, one has to use
> pointers.)
>
> In that sense, the lack of a qualifier in C, which matches Fortran, is
> "really really not helping optimizers". ;-)
Sure ;) What the middle-end currently lacks is explicit tracking of what
escapes through a function return as opposed to what escapes somewhere
else. Once that is implemented a flag on the PARM_DECL that tells
it to use Fortran dummy argument rules is easy to implement (but we
have issues when that dummy argument is an array descriptor and
the dummy argument rules also apply to the actual array data - as
opposed to, I presume, a dummy argument of fortran aggregate type
with a pointer member).
It's on my list to solve that function-return-escape thing, but as usual
my list of things to implement is rather large ;)
For the record, the current way of using C restrict works reasonably
well and I don't think we will gain very much in real-world performance
if not using it (though it might be cleaner to not piggy-back on the
odd C restrict semantics).
Richard.
Re: C++ mangling, function name to mangled name (or tree)
Le 13 juil. 2011 à 18:35, Pierre Vittet a écrit : > Hello, > > sorry to answer that late (I didn't saw your mail in my mailbox + I was > preparing me for RMLL/Libre software meeting). Yeah i know, i wanted to be there for your RMLL session, but i had to work on tuesday ! > > Your solution looks to be a nice one, I am goiing to try it and I will post > the result of my experiment. I was not aware of that hook. > > Thanks! > > Pierre Vittet At that time i didn't know you were working on Melt, and for now the few things i know about it is that it's mainly abut hooking the pass manager (or am i wrong ?) So all those useful events like PLUGIN_PRE_GENERICIZE or PLUGIN_FINISH_TYPE don't seems to be catchable through the Melt API (again, i'm maybe wrong, but if not it should be easy to add that feature to Melt). The main drawback of using PLUGIN_PRE_GENERICIZE to catch symbol declaration is that it is fired only for function body declaration. That's why i pinged an old patch adding a new event PLUGIN_FINISH_DECL. See http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg09792.html To get the full name of any declaration (ie like my_namespace::my_class::my_value or int::my_namespace::my_class::my_method (int, const char *)) just do: const char *fullname = lang_hooks.decl_printable_name (my_dec, 2l); (with #include "langhooks.h") That's exactly what current_function_name() does with current_function_decl. Romain Geissler
Re: C++ mangling, function name to mangled name (or tree)
Le 14 juil. 2011 à 12:42, Romain Geissler a écrit : > const char *fullname = lang_hooks.decl_printable_name (my_dec, 2l); Of course there is no 'l' at the end of the line. Just read: const char *fullname = lang_hooks.decl_printable_name (my_decl, 2);
Re: Ada boolean type
> I'm wondering why for Ada boolean_true_node has a value that is > not in the range of the Ada type but is, for the specific case, > 255 instead of 1. Is there a specific reason for that? None, boolean_true_node must be 1, that's why we (re)set it in gnat_init. > Does the following patch make sense (untested)? It's a no-op. TYPE_MAX_VALUE == TYPE_RM_MAX_VALUE if the latter exists. > Btw, I wonder if Ada cannot simply use its own boolean_type_node > global tree and leave the middle-ends boolean_type_node alone, > which is supposed to match the C ABI of the target. Only after Fortran does the same. :-) -- Eric Botcazou
Re: Ada boolean type
On Thu, 14 Jul 2011, Eric Botcazou wrote: > > I'm wondering why for Ada boolean_true_node has a value that is > > not in the range of the Ada type but is, for the specific case, > > 255 instead of 1. Is there a specific reason for that? > > None, boolean_true_node must be 1, that's why we (re)set it in gnat_init. > > > Does the following patch make sense (untested)? > > It's a no-op. TYPE_MAX_VALUE == TYPE_RM_MAX_VALUE if the latter exists. Oh, ok. So TYPE_MAX_VALUE gets re-set by SET_TYPE_RM_MAX_VALUE (boolean_type_node, build_int_cst (boolean_type_node, 1)); I would have thought that it sets something different from its comment: /* For numerical types, this is the RM upper bound of the type. There is again a discrepancy between this upper bound and the GCC upper bound, again because of the need to support invalid values. These values can be outside the range of values allowed by the RM upper bound but they must nevertheless be valid in the GCC type system, otherwise the optimizer can pretend that they simply don't exist. Therefore they must be within the range of values allowed by the upper bound in the GCC sense, hence the GCC upper bound be set to that of the base type. */ #define TYPE_RM_MAX_VALUE(NODE) TYPE_RM_VALUE ((NODE), 2) #define SET_TYPE_RM_MAX_VALUE(NODE, X) SET_TYPE_RM_VALUE ((NODE), 2, (X)) and from looking at SET_TYPE_RM_VALUEs definition it doesn't touch TYPE_MAX_VALUE. So TYPE_MAX_VALUE is as set from make_unsigned_type (8) which should set it to 255, not 1. So ... how can it be a no-op? > > Btw, I wonder if Ada cannot simply use its own boolean_type_node > > global tree and leave the middle-ends boolean_type_node alone, > > which is supposed to match the C ABI of the target. > > Only after Fortran does the same. :-) Heh ;) At least Fortran doesn't play games with TYPE_PRECISION ;) Richard.
Re: Ada boolean type
> and from looking at SET_TYPE_RM_VALUEs definition it doesn't > touch TYPE_MAX_VALUE. So TYPE_MAX_VALUE is as set from > make_unsigned_type (8) which should set it to 255, not 1. > > So ... how can it be a no-op? Look a few lines below. :-) In gigi we manipulate both full-fledged Ada types with RM bounds and GCC types without RM bounds so it's more convenient to have a single accessor macro. > Heh ;) At least Fortran doesn't play games with TYPE_PRECISION ;) Right, but TYPE_PRECISION isn't prescribed by the C ABI, is it? More seriously I think that your suggestion is the way to go and I made the same when we were fiddling with boolean_type_node in free_lang_data: http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00966.html So fine with me, as long as all the languages play by the same rules. -- Eric Botcazou
Re: Ada boolean type
On Thu, 14 Jul 2011, Eric Botcazou wrote: > > and from looking at SET_TYPE_RM_VALUEs definition it doesn't > > touch TYPE_MAX_VALUE. So TYPE_MAX_VALUE is as set from > > make_unsigned_type (8) which should set it to 255, not 1. > > > > So ... how can it be a no-op? > > Look a few lines below. :-) In gigi we manipulate both full-fledged Ada > types > with RM bounds and GCC types without RM bounds so it's more convenient to > have > a single accessor macro. /* For numerical types, this is the upper bound of the type, i.e. the RM upper bound for language-defined types and the GCC upper bound for others. */ #undef TYPE_MAX_VALUE #define TYPE_MAX_VALUE(NODE) \ (TYPE_RM_MAX_VALUE (NODE) \ ? TYPE_RM_MAX_VALUE (NODE) : TYPE_GCC_MAX_VALUE (NODE)) Ick ;) > > Heh ;) At least Fortran doesn't play games with TYPE_PRECISION ;) > > Right, but TYPE_PRECISION isn't prescribed by the C ABI, is it? More > seriously > I think that your suggestion is the way to go and I made the same when we > were > fiddling with boolean_type_node in free_lang_data: > http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00966.html > > So fine with me, as long as all the languages play by the same rules. Yeah, it'll be a (slow) migration process though. I'll eventually work on the Fortran parts. Richard.
Re: C++ mangling, function name to mangled name (or tree)
On 14/07/2011 12:42, Romain Geissler wrote: At that time i didn't know you were working on Melt, and for now the few things i know about it is that it's mainly abut hooking the pass manager (or am i wrong ?) So all those useful events like PLUGIN_PRE_GENERICIZE or PLUGIN_FINISH_TYPE don't seems to be catchable through the Melt API (again, i'm maybe wrong, but if not it should be easy to add that feature to Melt). Yeah, first use of MELT is to add new passes, however we have some others hooks, for exemple I already added a hook to use pragma in MELT. I am going to add a hook for PLUGIN_PRE_GENERICIZE in the MELT API. I saw your mail about pushing PLUGIN_FINISH_TYPE hook in the trunk, that will be very usefull for both MELT and plugins in a general sense. I have seen you were correcting things in the MELT build system, that is not easy I think Is it working ? Take me (and Basile) informed. From my system, it looks melt-sources directory is not correctly installed, moreover, I am not sure that meltgc_make_load_melt_module (in melt-runtime.c) search correctly this source (for exemple I can't understand why we try to find them in temporary directory). Basile Starynkevitch does not work this week (normally), however, I am sure, he will help us when he came back. Pierre Vittet
Re: A visualization of GCC's passes, as a subway map
Hi, On Thu, 14 Jul 2011, Paolo Bonzini wrote: > On 07/14/2011 11:11 AM, Richard Guenther wrote: > > > > > > Hm, why? complex operations are lowered after a complex lowering > > > > > > pass > > > > > > has executed. they are still lowered on RTL, so I don't see why we > > > > > > need > > > > > > to destroy them technically. > > > > > > > > Because it's PROP_*gimple*_lcx.:) > > Shouldn't it then be PROP_*gimple* instead of PROP_*trees*?;) > > Heh, you have a point! I think until and unless we have verifiers for the properties, and automatic (re)setting them for at least the common ones, it's all just wasted work. They don't provide any useful info whatsoever. The only useful ones are: PROP_cfg, PROP_rtl, PROP_trees (for adjusting what is dumped, arguably possible to check differently) and PROP_ssa (for remove_unused_locals). The rest is just snake oil. Ciao, Michael.
Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
Hi, On Thu, 14 Jul 2011, Richard Guenther wrote: > Sure ;) What the middle-end currently lacks is explicit tracking of > what escapes through a function return as opposed to what escapes > somewhere else. Once that is implemented a flag on the PARM_DECL that > tells it to use Fortran dummy argument rules is easy to implement (but > we have issues when that dummy argument is an array descriptor and the > dummy argument rules also apply to the actual array data - as opposed > to, I presume, a dummy argument of fortran aggregate type with a pointer > member). And the latter is also why such a flag/attribute needs to be ultimately placed on the type, so that we can form pointers to such parm_decls (or even members of array descriptors) without loosing the special guarantees, ala "not clobbered by calls". That or flags on the MEM_REF (which magically needs to be set then, most probably again, by tracking such flag from the PARM_DECL, through types to the MEM_REF). > It's on my list to solve that function-return-escape thing, but as usual > my list of things to implement is rather large ;) > > For the record, the current way of using C restrict works reasonably > well and I don't think we will gain very much in real-world performance > if not using it Did you really want to say this? Because I'm very sure we actually loose very much in real-world performance if we wouldn't be using it (or some alterntive that is specified somewhat cleaner). Ciao, Michael.
Re: C++ mangling, function name to mangled name (or tree)
Le 14 juil. 2011 à 16:08, Pierre Vittet a écrit : > I have seen you were correcting things in the MELT build system, that is not > easy I think Is it working ? Take me (and Basile) informed. From my > system, it looks melt-sources directory is not correctly installed, moreover, > I am not sure that meltgc_make_load_melt_module (in melt-runtime.c) search > correctly this source (for exemple I can't understand why we try to find them > in temporary directory). I have come out to something that build as a plugin, and i am now trying to apply more or less the same changes to the melt-branch. However the branch won't built for now. It fails during check-melt-runtime because of warnings melt is throwings with -Werror. If it fails at the runtime checks, it's almost over and i think i'm near something that builds. I have to correct a few warnings in warmelt-ana-simple and see what's the next unexpected warning ! I'll post this when it both work as a plugin and with the whole branch.
Re: RFH: Impose code-movement restrictions and value assumption (for ASYNCHRONOUS/Coarrays)
Hello,
On Wednesday 13 July 2011 15:46:37 Tobias Burnus wrote:
>
> void some_function(void);
>
> void
> sub (int *restrict non_aliasing_var)
> {
>*non_aliasing_var = 5;
>some_function ();
>if (*non_aliasing_var != 5)
> foobar_();
> }
>
Couldn't we simulate the desired behaviour with more than one decl, one of
them const qualified? Like so:
void
sub (int *restrict non_aliasing_var)
{
*non_aliasing_var = 5;
{
const int *non_aliasing_var_tmp = non_aliasing_var;
some_function ();
if (*non_aliasing_var_tmp != 5)
foobar_();
}
}
It would probably be a hell to implement however.
Mikael
gcc-4.5-20110714 is now available
Snapshot gcc-4.5-20110714 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110714/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 176288 You'll find: gcc-4.5-20110714.tar.bz2 Complete GCC MD5=efe84cbba333aa5c1354b064e69e0932 SHA1=8edbd70fe6393a78f23eff079f068a29f4a4 Diffs from 4.5-20110707 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.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.
