Re: Enabling a function based on Language
Ian Lance Taylor wrote: "Iyer, Balaji V" writes: Is there a #define in GCC that will turn on only for certain languages? I am trying to use build_array_ref but it is giving me a undefined reference for f951. This code that I am trying to use will ONLY execute if we have a C/C++ code. Is it possible for me to enclose this inside some #defines (or a combination of them)? By definition, no, there isn't. The middle-end is compiled once, into a library. Then each frontend is linked against that library. Calling a frontend function like build_array_ref from the middle-end is always a mistake. In the middle-end you should probably be making a POINTER_PLUS_EXPR node or something along those lines. Unless, of course, one goes the route which Richard once suggested: Adding array and scalarizer support to the middle end, http://gcc.gnu.org/wiki/GCCGathering2011Fortran#Scalarizer (See all three links; mistakes in the Wiki are mine, made when I tried to summarize/understand Richard's draft patches. The project got stalled as there was not enough developer time on the Fortran side and as the current approach works relatively well. ME support would be beneficial as it would allow for certain optimizations which are not possible in the front end.) Tobias
RE: A question about loop ivopt
> -Original Message- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: Tuesday, May 15, 2012 10:17 PM > To: Zdenek Dvorak > Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu > Subject: Re: A question about loop ivopt > > On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak > wrote: > > Hi, > > > >> > > > Why can't we replace function force_expr_to_var_cost directly > with > >> function > >> > > > computation_cost in tree-ssa-loop-ivopt.c? > >> > > > > >> > > > Actually I think it is inaccurate for the current recursive > algorithm > >> in > >> > > > force_expr_to_var_cost to estimate expr cost. Instead > >> computation_cost can > >> > > > count some back-end factors and make the estimation more > accurate. > >> > > > > >> > > > For example, using computation_cost, we may check whether > back-ends > >> can tie > >> > > > some modes transformation expressed by SUBREG or not. If we > use > >> > > > force_expr_to_var_cost, some more computations around type > >> > > > promotion/demotion would increase the cost estimated. > >> > > > > >> > > > Looking at the algorithm in force_expr_to_var_cost, it is just > to > >> analyze > >> > > > the operator in the expression and give estimation. Should it > be the > >> same as > >> > > > expanding EXPR to RTX and give estimation like in > computation_cost? > >> > > > > >> > > > Any thoughts? > >> > > > >> > > I suppose Zdenek may remember. > >> > > >> > computation_cost actually expands the expression to RTL. Since > cost > >> estimates > >> > are computed a lot in ivopts, using it directly would require a > huge > >> amount of memory, > >> > >> Zdenek, > >> > >> Do you know how huge is it? Any data on this? For GCC, is this > "huge" > >> memory consumption is critical enough, and there aren't any other > else > >> consuming even more memory? > > > > no, not really (I haven't worked on this for a few years now), > although > > of course I did some measurements when ivopts were created. Feel > free > > to experiment with that, if it turned out that the memory consumption > > and extra time spent by it is negligible, it would be a nice cleanup. > > Well, I don't think we should feed arbitrary expressions to expand at > IVOPTs time. What probably matters most is address costs, no? > At least that is where expand probably makes the most difference. > So why not improve force_expr_to_var_cost instead? OK, yes, the thing that matter most is just address cost, so I can improve force_expr_to_var_cost. Would it sound OK if I expose MODES_TIEABLE_P to middle-end by defining a new target hook? I need this function to strip some operations and make the cost estimate more accurate. If I don't expand to RTL, I would need a method to check the modes conversion in middle end, anyway. Any idea? Thanks, -Jiangning > > Richard. > > > > Zdenek
Re: A question about loop ivopt
On Tue, May 22, 2012 at 11:19 AM, Jiangning Liu wrote: > > >> -Original Message- >> From: Richard Guenther [mailto:richard.guent...@gmail.com] >> Sent: Tuesday, May 15, 2012 10:17 PM >> To: Zdenek Dvorak >> Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu >> Subject: Re: A question about loop ivopt >> >> On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak >> wrote: >> > Hi, >> > >> >> > > > Why can't we replace function force_expr_to_var_cost directly >> with >> >> function >> >> > > > computation_cost in tree-ssa-loop-ivopt.c? >> >> > > > >> >> > > > Actually I think it is inaccurate for the current recursive >> algorithm >> >> in >> >> > > > force_expr_to_var_cost to estimate expr cost. Instead >> >> computation_cost can >> >> > > > count some back-end factors and make the estimation more >> accurate. >> >> > > > >> >> > > > For example, using computation_cost, we may check whether >> back-ends >> >> can tie >> >> > > > some modes transformation expressed by SUBREG or not. If we >> use >> >> > > > force_expr_to_var_cost, some more computations around type >> >> > > > promotion/demotion would increase the cost estimated. >> >> > > > >> >> > > > Looking at the algorithm in force_expr_to_var_cost, it is just >> to >> >> analyze >> >> > > > the operator in the expression and give estimation. Should it >> be the >> >> same as >> >> > > > expanding EXPR to RTX and give estimation like in >> computation_cost? >> >> > > > >> >> > > > Any thoughts? >> >> > > >> >> > > I suppose Zdenek may remember. >> >> > >> >> > computation_cost actually expands the expression to RTL. Since >> cost >> >> estimates >> >> > are computed a lot in ivopts, using it directly would require a >> huge >> >> amount of memory, >> >> >> >> Zdenek, >> >> >> >> Do you know how huge is it? Any data on this? For GCC, is this >> "huge" >> >> memory consumption is critical enough, and there aren't any other >> else >> >> consuming even more memory? >> > >> > no, not really (I haven't worked on this for a few years now), >> although >> > of course I did some measurements when ivopts were created. Feel >> free >> > to experiment with that, if it turned out that the memory consumption >> > and extra time spent by it is negligible, it would be a nice cleanup. >> >> Well, I don't think we should feed arbitrary expressions to expand at >> IVOPTs time. What probably matters most is address costs, no? >> At least that is where expand probably makes the most difference. >> So why not improve force_expr_to_var_cost instead? > > OK, yes, the thing that matter most is just address cost, so I can improve > force_expr_to_var_cost. > > Would it sound OK if I expose MODES_TIEABLE_P to middle-end by defining a > new target hook? I need this function to strip some operations and make the > cost estimate more accurate. If I don't expand to RTL, I would need a method > to check the modes conversion in middle end, anyway. Any idea? You are already in the middle-end and thus can use MODES_TIABLE_P directly. Modes are also available on gimple variables via DECL/TYPE_MODE. Richard. > Thanks, > -Jiangning > >> >> Richard. >> >> >> > Zdenek > > > >
C++98/C++11 ABI compatibility for gcc-4.7
I've put together the following description of C++98/11 ABI
(in)compatibility, so people can tell which libraries need to be
recompiled. This is useful when you've bought a library that didn't
come with source code, and you're trying to figure out if you need to
buy a new version. I think this belongs on the Wiki somewhere, but I
wanted to run it by the list first to make sure it's accurate. You can
probably skip the first section, since it's just a description of how
to use the subsequent list.
This page explains how to identify when your pre-compiled library (.a
or .so) defines a symbol that has a different enough definition in
C++98 vs C++11 that it could cause runtime problems if it's linked
into a program compiled for the other version.
First, get a list of demangled symbols from your .a or .so:
$ (find . -name '*.a'|xargs nm -f posix; find . -name '*.so' | xargs
nm -f posix -D)|cut -f1 -d' '|LANG=C sort -u|c++filt|sort
(There may be better ways to get this list.)
Next, find instances in this list of the ABI changes listed below.
For example, you might find:
std::_List_base >::_M_clear()
Since std::_List_base::_M_clear() destroys nodes, it's affected by the
addition of the _M_size field and can't be used by C++11 code if it
was compiled for C++98, or vice versa. If it's possible that code
outside the library would use this instance of _List_base, then you
have to recompile the library. On the other hand, if FooBar is a type
used only inside this library, then code using the library is safe.
If FooBar is defined by the library but exposed in one of the
library's headers, then the library still needs to be recompiled,
since code using it could wind up including the other version's
implementation.
=== ABI Changes ===
complex::{real,imag}(), std::{real,imag}(complex)
The non-const overloads go from returning _Tp& to _Tp.
[Since gcc-4.4]
std::list, std::_List_impl, and std::_List_base
New _M_size member, meaning any method that adds or removes nodes or
inspects the size has a new ABI.
[Since gcc-4.7]
std::operator-(reverse_iterator) and std::operator-(__normal_iterator)
may return a different type if
reverse_iterator<_IteratorL>::difference_type (respectively,
__normal_iterator<_IteratorL, _Container>::difference_type) isn't
accurate.
[Since gcc-4.4]
map::erase(iterator), multimap::erase(iterator),
set::erase(const_iterator), set::erase(const_iterator,
const_iterator), multiset::erase(const_iterator),
multiset::erase(const_iterator, const_iterator):
Return type changes from void to iterator.
[Since gcc-4.5]
_Rb_tree::erase(const_iterator), _Rb_tree::erase(const_iterator, const_iterator), _Rb_tree::erase(iterator):
Return type changes from void to iterator. these are instantiated from
map and set.
[Since gcc-4.5]
vector::data()'s return type changes from pointer to _Tp*
This is a no-op with most allocators, but any allocator that defines a
non-default pointer typedef will be incompatible.
[Since gcc-4.6]
Probably safe: istreambuf_iterator::reference changes from _CharT& to _CharT.
This could affect return types if they mention 'reference', but they
appear not to mention it when istreambuf_iterator is involved.
[Since gcc-4.7]
Probably safe: map::erase(iterator, iterator),
multimap::erase(iterator, iterator)
C++11 uses const_iterator, which doesn't collide. Other versions of
gcc are unlikely to have defined this overload in C++98 mode, and
C++11 is unlikely to have defined the iterator version.
[Since gcc-4.5]
Probably safe: Types with node allocators, like deque and tree
C++11 uses _M_get_Node_allocator().construct(node, ...), while C++98
uses get_allocator().construct(node->_M_value_field, ...). The node's
constructor forwards to the value_field's constructor, so this works
by default. Can this cause problems with some mix of C++98/C++11
allocator compilations?
I haven't analyzed the debug and profile headers.
I found these differences by grepping for GXX_EXPERIMENTAL_CXX0X
inside libstdc++, and examining each instance to see if there was an
#else clause that had different behavior in C++11 vs C++98.
=== ABI non-changes ===
libstdc++'s binary component is nearly ABI-compatible between C++98
and C++11. Most incompatibilities are in the templates defined in
headers, but the complex<> stream operators call the real() and imag()
methods that change return type. If these calls aren't inlined, (and
they're likely to be inlined), then libstdc++ (which is compiled in
C++98 mode by default) could cause problems when linked into C++11
programs. (http://gcc.gnu.org/PR53429)
There have been some claims that the change in the definition of POD
types causes an ABI incompatibility, but apparently it doesn't in
practice: http://gcc.gnu.org/ml/gcc/2012-01/msg00056.html.
RE: Enabling a function based on Language
Thanks Tobias, I am wanting to call this function right before we hit the gimplify_function_tree (), so I guess I am right before the middle-end... -Balaji V. Iyer. -Original Message- From: Tobias Burnus [mailto:bur...@net-b.de] Sent: Tuesday, May 22, 2012 3:25 AM Cc: i...@google.com; Iyer, Balaji V; 'gcc@gcc.gnu.org' Subject: Re: Enabling a function based on Language Ian Lance Taylor wrote: > "Iyer, Balaji V" writes: > >> Is there a #define in GCC that will turn on only for certain languages? >> I am trying to use build_array_ref but it is giving me a undefined reference >> for f951. This code that I am trying to use will ONLY execute if we have a >> C/C++ code. Is it possible for me to enclose this inside some #defines (or >> a combination of them)? > > By definition, no, there isn't. The middle-end is compiled once, into > a library. Then each frontend is linked against that library. > > Calling a frontend function like build_array_ref from the middle-end > is always a mistake. In the middle-end you should probably be making > a POINTER_PLUS_EXPR node or something along those lines. Unless, of course, one goes the route which Richard once suggested: Adding array and scalarizer support to the middle end, http://gcc.gnu.org/wiki/GCCGathering2011Fortran#Scalarizer (See all three links; mistakes in the Wiki are mine, made when I tried to summarize/understand Richard's draft patches. The project got stalled as there was not enough developer time on the Fortran side and as the current approach works relatively well. ME support would be beneficial as it would allow for certain optimizations which are not possible in the front end.) Tobias
Re: MULTILIB_OPTIONS and DRIVER_SELF_SPEC
On 21/05/12 15:21, Christian Bruel wrote: Options not explicitly described in the compiler before their use in a spec rules are now rejected. So you probably need to describe it into your target optimization file, (something like xap.opt). OK, thanks for letting me know about this. Cheers, -- PMatos
RE: A question about loop ivopt
> -Original Message- > From: Richard Guenther [mailto:richard.guent...@gmail.com] > Sent: Tuesday, May 22, 2012 6:36 PM > To: Jiangning Liu > Cc: Zdenek Dvorak; Jiangning Liu; gcc@gcc.gnu.org > Subject: Re: A question about loop ivopt > > On Tue, May 22, 2012 at 11:19 AM, Jiangning Liu > wrote: > > > > > >> -Original Message- > >> From: Richard Guenther [mailto:richard.guent...@gmail.com] > >> Sent: Tuesday, May 15, 2012 10:17 PM > >> To: Zdenek Dvorak > >> Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu > >> Subject: Re: A question about loop ivopt > >> > >> On Tue, May 15, 2012 at 4:13 PM, Zdenek Dvorak > >> wrote: > >> > Hi, > >> > > >> >> > > > Why can't we replace function force_expr_to_var_cost > directly > >> with > >> >> function > >> >> > > > computation_cost in tree-ssa-loop-ivopt.c? > >> >> > > > > >> >> > > > Actually I think it is inaccurate for the current recursive > >> algorithm > >> >> in > >> >> > > > force_expr_to_var_cost to estimate expr cost. Instead > >> >> computation_cost can > >> >> > > > count some back-end factors and make the estimation more > >> accurate. > >> >> > > > > >> >> > > > For example, using computation_cost, we may check whether > >> back-ends > >> >> can tie > >> >> > > > some modes transformation expressed by SUBREG or not. If we > >> use > >> >> > > > force_expr_to_var_cost, some more computations around type > >> >> > > > promotion/demotion would increase the cost estimated. > >> >> > > > > >> >> > > > Looking at the algorithm in force_expr_to_var_cost, it is > just > >> to > >> >> analyze > >> >> > > > the operator in the expression and give estimation. Should > it > >> be the > >> >> same as > >> >> > > > expanding EXPR to RTX and give estimation like in > >> computation_cost? > >> >> > > > > >> >> > > > Any thoughts? > >> >> > > > >> >> > > I suppose Zdenek may remember. > >> >> > > >> >> > computation_cost actually expands the expression to RTL. Since > >> cost > >> >> estimates > >> >> > are computed a lot in ivopts, using it directly would require a > >> huge > >> >> amount of memory, > >> >> > >> >> Zdenek, > >> >> > >> >> Do you know how huge is it? Any data on this? For GCC, is this > >> "huge" > >> >> memory consumption is critical enough, and there aren't any other > >> else > >> >> consuming even more memory? > >> > > >> > no, not really (I haven't worked on this for a few years now), > >> although > >> > of course I did some measurements when ivopts were created. Feel > >> free > >> > to experiment with that, if it turned out that the memory > consumption > >> > and extra time spent by it is negligible, it would be a nice > cleanup. > >> > >> Well, I don't think we should feed arbitrary expressions to expand > at > >> IVOPTs time. What probably matters most is address costs, no? > >> At least that is where expand probably makes the most difference. > >> So why not improve force_expr_to_var_cost instead? > > > > OK, yes, the thing that matter most is just address cost, so I can > improve > > force_expr_to_var_cost. > > > > Would it sound OK if I expose MODES_TIEABLE_P to middle-end by > defining a > > new target hook? I need this function to strip some operations and > make the > > cost estimate more accurate. If I don't expand to RTL, I would need a > method > > to check the modes conversion in middle end, anyway. Any idea? > > You are already in the middle-end and thus can use MODES_TIABLE_P > directly. Modes are also available on gimple variables via > DECL/TYPE_MODE. Richard, But MODES_TIEABLE_P is a macro hook and isn't exposed to TREE level, so I would have to modify xxx-protos.h for all back-ends. An alternative way is I define a new function hook. This way I needn't to change all back-ends, but support several back-ends required first. Which solution is usually preferred? Thanks, -Jiangning > > Richard. > > > Thanks, > > -Jiangning > > > >> > >> Richard. > >> > >> > >> > Zdenek > > > > > > > >
Re: A question about loop ivopt
On Tue, May 22, 2012 at 8:04 PM, Jiangning Liu wrote: > Richard, > > But MODES_TIEABLE_P is a macro hook and isn't exposed to TREE level, so I > would have to modify xxx-protos.h for all back-ends. As far as I can tell it is exposed already to the middle-end via that hook in that you should be able to use MODES_TIEABLE_P from tree-ssa-loop-ivopts.c without modifying anything else. It looks like the arm and i386 are have both broken xxx-protos.h. Both rs6000 and mips will work without touching their xxx-protos.h. I think it is better if you just fix the targets which have a broken xxx-protos.h. Thanks, Andrew Pinski > > An alternative way is I define a new function hook. This way I needn't to > change all back-ends, but support several back-ends required first. > > Which solution is usually preferred? > > Thanks, > -Jiangning > >> >> Richard. >> >> > Thanks, >> > -Jiangning >> > >> >> >> >> Richard. >> >> >> >> >> >> > Zdenek >> > >> > >> > >> > > > > >
