predicates on expressions ?
I was wondering if it was a good idea to implement predicate on expressions ? Sth like: (match_and_simplify (op (op2:predicate @0)) transform) instead of: (match_and_simplify (op (op2@1 @0)) if (predicate (@1)) transform) When predicate is simple as just being a macro/function, we could use this style and when the predicate is more complex resort to using if-expr (or write the predicate as macro in gimple-match-head.c and use the macro in pattern instead ...) Example: we could rewrite the pattern (match_and_simplify (plus:c @0 (negate @1)) if (!TYPE_SATURATING (type)) (minus @0 @1)) to (match_and_simplify (plus:c:NOT_TYPE_SATURATING_P @0 (negate @1)) (minus @0 @1)) with NOT_TYPE_SATURATING_P predicate defined appropriately in gimple-match-head.c However I am not entirely sure if adding predicates on expressions would be very useful Thanks and Regards, Prathamesh
Re: GCC 4.9.1 Status Report (2014-07-10)
Hi Chris, no way!
It is like if gcc do not take in account of my BUILD_CFLAGS="-g -O2
-fbracket-depth=1024“
I even tried N=2048!
/opt/uKOS/Packages/gcc-4.9.1/gcc/config/arm/neon.md:3486:10917: fatal error:
bracket nesting level exceeded maximum of 256
/opt/uKOS/Packages/gcc-4.9.1/gcc/config/arm/neon.md:3486:10917: note: use
-fbracket-depth=N to increase maximum nesting level
32 warnings and 1 error generated.
make[1]: *** [insn-attrtab.o] Error 1
make: *** [all-gcc] Error 2
Error building gcc pass 1
here is my script for building gcc …
cd ${PATH_TOOLS_GCC}/Packages
echo "Start building:" > gcc_pass1.txt
date >> gcc_pass1.txt
mkdir -p ${PATH_TOOLS_GCC}/builds/gcc-${GCC_VER}/${MACHINE}/gcc-${GCC_VER}
cd ${PATH_TOOLS_GCC}/builds/gcc-${GCC_VER}/${MACHINE}/gcc-${GCC_VER}
BUILD_CFLAGS="-g -O2 -fbracket-depth=1024"
${PATH_TOOLS_GCC}/Packages/gcc-${GCC_VER}/configure \
--target=${TARGET} \
--includedir=/usr/include \
--prefix=${prefix} \
--enable-multilib \
--disable-werror \
--disable-nls \
--disable-libssp \
${GCC1_CONFIG} || { echo "Error configuring gcc pass 1"; exit 1; }
make all-gcc|| { echo "Error building gcc pass 1";exit 1; }
make install-gcc|| { echo "Error installing gcc pass 1"; exit 1; }
cd ${PATH_TOOLS_GCC}/Packages
echo "End building:" >> gcc_pass1.txt
date >> gcc_pass1.txt
mv gcc_pass1.txt gcc_pass1_ready.txt
Edo.
On 14 Jul 2014, at 05:01, Chris Johns wrote:
> On 13/07/2014 3:38 am, Franzi Edo. wrote:
>> Hi James (all),
>> Thank you for all of your suggestions.
>> I tried everything unsuccessfully. Unfortunately, the
>>
>> make CFLAGS="-g -O2 -fbracket-depth=1024”
>> and the
>> make BUILD_CFLAGS="-g -O2 -fbracket-depth=1024”
>> do not solve the problem.
>
> Please add 'BUILD_CFLAGS="-g -O2 -fbracket-depth=1024”' to the configure
> command line before the configure script is referenced, ie:
>
> $ BUILD_CFLAGS="-g -O2 -fbracket-depth=1024” ../gcc-4.9.0/configure ...
>
> Chris
Re: predicates on expressions ?
On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni wrote: > I was wondering if it was a good idea to implement > predicate on expressions ? > > Sth like: > (match_and_simplify > (op (op2:predicate @0)) > transform) > > instead of: > (match_and_simplify > (op (op2@1 @0)) > if (predicate (@1)) > transform) > > When predicate is simple as just being a macro/function, > we could use this style and when the predicate is more complex > resort to using if-expr (or write the predicate as macro in > gimple-match-head.c > and use the macro in pattern instead ...) > > Example: > we could rewrite the pattern > (match_and_simplify > (plus:c @0 (negate @1)) > if (!TYPE_SATURATING (type)) > (minus @0 @1)) > > to > > (match_and_simplify > (plus:c:NOT_TYPE_SATURATING_P @0 (negate @1)) > (minus @0 @1)) > > with NOT_TYPE_SATURATING_P predicate defined > appropriately in gimple-match-head.c > > However I am not entirely sure if adding predicates on expressions > would be very useful Well. I think there are two aspects to this. First is pattern readability where I think that the if-expr form is more readable. Second is the ability to do less work in the code generated from the decision tree. For example most of the patterns from associate_plusminus still miss the !TYPE_SATURATING && !FLOAT_TYPE_P && !FIXED_POINT_TYPE_P if-expr. That is, we'd have /* (A +- B) - A -> +-B. */ (match_and_simplify (minus (plus @0 @1) @0) if (!TYPE_SATURATING (type) && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) @1) (match_and_simplify (minus (minus @0 @1) @0) if (!TYPE_SATURATING (type) && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) (negate @1)) /* (A +- B) -+ B -> A. */ (match_and_simplify (minus (plus @0 @1) @1) if (!TYPE_SATURATING (type) && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) @0) (match_and_simplify (plus:c (minus @0 @1) @1) if (!TYPE_SATURATING (type) && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) @0) with code-generation checking the if-expr after matching. And with using expression predicates we'd be able to check the predicate when matching the outermost 'minus' and "CSE" the predicate check for the first three patterns. Runtime-wise it depends on whether there is a point to back-track to. I would say it's more interesting to support if (!TYPE_SATURATING (type) && !FLOAT_TYPE_P (type) && !FiXED_POINT_TYPE_P (type)) (match_and_simplify ) (match_and_simplify ) and treat this if-expression like a predicate on the outermost expression. That's getting both benefits (bah, the free-form if-expr makes it ugly, what do we use as grouping syntax? I guess wrapping the whole thing in ()s, similar to (for ...)). Richard. > Thanks and Regards, > Prathamesh
Re: GCC 4.9.1 Status Report (2014-07-10)
Hi, On Mon, 14 Jul 2014, Franzi Edo. wrote: > It is like if gcc do not take in account of my BUILD_CFLAGS="-g -O2 > -fbracket-depth=1024“ GCC meanwhile is compiled with c++. Instead of CFLAGS use CXXFLAGS. I.e. BUILD_CXXFLAGS, and so on. No guarantees, but at least foobar_CFLAGS only should not be enough. Ciao, Michael.
Why is unsigned type introduced in a simple case?
Hi,
For a simple example like below.
int
f1 (int p, short i, short n)
{
int sum = 0;
do
{
sum += i;
i++;
}
while (i < n);
return sum;
}
When compiling with -O2 -fdump-tree-all options, GCC introduces
unsigned type at the very beginning of gimple pass, for example, the
dump for gimple pass is like below.
f1 (int p, short int i, short int n)
{
int D.4116;
short int i.0;
unsigned short i.1;
unsigned short D.4119;
int D.4120;
int sum;
sum = 0;
:
D.4116 = (int) i;
sum = D.4116 + sum;
i.0 = i;
i.1 = (unsigned short) i.0;
D.4119 = i.1 + 1;
i = (short int) D.4119;
if (i < n) goto ; else goto ;
:
D.4120 = sum;
return D.4120;
}
It uses i.1 to increase the induction variable and converts it back to
signed type for comparison. Is it designed behavior? &why?
Thanks,
bin
Re: Why is unsigned type introduced in a simple case?
> On Jul 14, 2014, at 8:57 AM, "Bin.Cheng" wrote:
>
> Hi,
> For a simple example like below.
>
> int
> f1 (int p, short i, short n)
> {
> int sum = 0;
>
> do
>{
> sum += i;
> i++;
This here is the same as i = i + 1; which is really
i = (short)(((int)i) + 1);
So it gets convert to using unsigned short to avoid undefined overflow ness of
signed types (which is part of gcc's ir).
Thanks,
Andrew
>}
> while (i < n);
>
> return sum;
> }
>
> When compiling with -O2 -fdump-tree-all options, GCC introduces
> unsigned type at the very beginning of gimple pass, for example, the
> dump for gimple pass is like below.
> f1 (int p, short int i, short int n)
> {
> int D.4116;
> short int i.0;
> unsigned short i.1;
> unsigned short D.4119;
> int D.4120;
> int sum;
>
> sum = 0;
> :
> D.4116 = (int) i;
> sum = D.4116 + sum;
> i.0 = i;
> i.1 = (unsigned short) i.0;
> D.4119 = i.1 + 1;
> i = (short int) D.4119;
> if (i < n) goto ; else goto ;
> :
> D.4120 = sum;
> return D.4120;
> }
>
> It uses i.1 to increase the induction variable and converts it back to
> signed type for comparison. Is it designed behavior? &why?
>
> Thanks,
> bin
Multilib build question involving MULTILIB_OSDIRNAMES
I have a multilib question that I hope someone can help me with.
If I have this multilib setup while building a cross compiler:
MULTILIB_DEFAULTS { "mips32r2" }
MULTILIB_OPTIONS = mips32r2/mips64r2
MULTILIB_OSDIRNAMES = ../lib ../lib64
Everything works the way I want it to. I have mips32r2 system libraries
in /lib under my sysroot and mips64r2 system libraries in /lib64 and
everything seems fine.
Now I want to make mips64r2 the default compilation mode for GCC but
I want to keep my sysroot setup (/lib for mips32r2 and /lib64 for mips64r2)
the same. So I change MULTILIB_DEFAULTS to specify "mips64r2" and rebuild.
When I do this, a default build (targeting mips64r2) searches for system
libraries in /lib instead of /lib64. Is there a way to fix this without
having to put mips64r2 system libraries in /lib? Is this the expected
behaviour or is this a bug in handling MULTILIB_OSDIRNAMES?
Steve Ellcey
sell...@mips.com
Re: GCC 4.9.1 Status Report (2014-07-10)
Hi Michael (all), Thank you for that! Unfortunately, even with BUILD_CXXFLAGS I have the same error …. Ciao Edo On 14 Jul 2014, at 16:53, Michael Matz wrote: > Hi, > > On Mon, 14 Jul 2014, Franzi Edo. wrote: > >> It is like if gcc do not take in account of my BUILD_CFLAGS="-g -O2 >> -fbracket-depth=1024“ > > GCC meanwhile is compiled with c++. Instead of CFLAGS use CXXFLAGS. I.e. > BUILD_CXXFLAGS, and so on. No guarantees, but at least foobar_CFLAGS only > should not be enough. > > > Ciao, > Michael.
Re: predicates on expressions ?
On Mon, Jul 14, 2014 at 6:35 PM, Richard Biener wrote: > On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni > wrote: >> I was wondering if it was a good idea to implement >> predicate on expressions ? >> >> Sth like: >> (match_and_simplify >> (op (op2:predicate @0)) >> transform) >> >> instead of: >> (match_and_simplify >> (op (op2@1 @0)) >> if (predicate (@1)) >> transform) >> >> When predicate is simple as just being a macro/function, >> we could use this style and when the predicate is more complex >> resort to using if-expr (or write the predicate as macro in >> gimple-match-head.c >> and use the macro in pattern instead ...) >> >> Example: >> we could rewrite the pattern >> (match_and_simplify >> (plus:c @0 (negate @1)) >> if (!TYPE_SATURATING (type)) >> (minus @0 @1)) >> >> to >> >> (match_and_simplify >> (plus:c:NOT_TYPE_SATURATING_P @0 (negate @1)) >> (minus @0 @1)) >> >> with NOT_TYPE_SATURATING_P predicate defined >> appropriately in gimple-match-head.c >> >> However I am not entirely sure if adding predicates on expressions >> would be very useful > > Well. I think there are two aspects to this. First is pattern > readability where I think that the if-expr form is more readable. > Second is the ability to do less work in the code generated > from the decision tree. > > For example most of the patterns from associate_plusminus > still miss the !TYPE_SATURATING && !FLOAT_TYPE_P && > !FIXED_POINT_TYPE_P if-expr. That is, we'd have > > /* (A +- B) - A -> +-B. */ > (match_and_simplify > (minus (plus @0 @1) @0) > if (!TYPE_SATURATING (type) > && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) > @1) > (match_and_simplify > (minus (minus @0 @1) @0) > if (!TYPE_SATURATING (type) > && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) > (negate @1)) > /* (A +- B) -+ B -> A. */ > (match_and_simplify > (minus (plus @0 @1) @1) > if (!TYPE_SATURATING (type) > && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) > @0) > (match_and_simplify > (plus:c (minus @0 @1) @1) > if (!TYPE_SATURATING (type) > && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) > @0) > > with code-generation checking the if-expr after matching. And > with using expression predicates we'd be able to check the > predicate when matching the outermost 'minus' and "CSE" > the predicate check for the first three patterns. Runtime-wise > it depends on whether there is a point to back-track to. > > I would say it's more interesting to support > > if (!TYPE_SATURATING (type) && !FLOAT_TYPE_P (type) && > !FiXED_POINT_TYPE_P (type)) >(match_and_simplify ) >(match_and_simplify ) > > > and treat this if-expression like a predicate on the outermost > expression. That's getting both benefits > (bah, the free-form if-expr makes it ugly, what do we use as > grouping syntax? I guess wrapping the whole thing in ()s, > similar to (for ...)). Um, I was wondering instead of defining new syntax if it would be better to make genmatch detect common if-expr and hoist them ? I suppose we could compare if-expr's lexicographically ? However I guess having some syntax to group common if-expr patterns explicitly would avoid the need for writing the if-expr in each pattern. For now should we go with free-form if ? If desired, we could change syntax later to something else (only parsing code need change, the rest would be in place). If we change the syntax for outer-if, for consistency should we also change syntax of inner if ? Thanks and Regards, Prathamesh > > Richard. > >> Thanks and Regards, >> Prathamesh
