Re: [GSoC] user defined predicates
On Fri, Aug 8, 2014 at 1:16 AM, Prathamesh Kulkarni wrote: > Currently, we treat predicates as "second-class" citizens: > - assume any identifier as a valid predicate > - cannot write more complex predicates than an identifier in match-op > > I was wondering whether it would be a good idea > to ave user-defined predicates, > instead of hard-coding them as macros in gimple-match-head.c ? > > * Syntax > A predicate is assumed to expect only one operand as input. > > (define_predicate (c_expr)) > > and use it the same way we do currently. > > Example Use case: > Consider following pattern: > (simplify > (foo @0 @1) > (if (TYPE_UNSIGNED (TREE_TYPE (@1))) > @0) > > The second operand (@1) is only captured for sake of testing it's type > in if-expr. > > Instead, define a predicate: > (define_predicate type_unsigned_p (TYPE_UNSIGNED (TREE_TYPE (@@))) > @@ refers to the operand we use the predicate on. > > (simplify >(foo @0 type_unsigned) >@0) > > in this case @@ would be op21 (one of the generated temporaries during > code-gen for match-op in decision tree). > > * code-gen > We would generate predicates as macros in the generated file. > so in gimple-match.c, there would be > #define type_unsigned(op) (TYPE_UNSIGNED (TREE_TYPE (op))) > (we also need this for generic-match.c, so maybe generate macros in > separate file say genpreds.c and include it in both gimple-match.c and > generic-match.c) > > and replace @@ by correct operand in the patterns the predicates > are used. > > The current "predicates" in gimple-match-head.c can be written as: > (define_predicate INTEGER_CST_P (TREE_CODE (@@) == INTEGER_CST))) > (define_predicate integral_op_p (INTEGRAL_TYPE_P (TREE_TYPE (@@))) > > Not sure if this would have real benefit, just an idea... My line of thinking was that if there are new predicates that are useful for writing patterns then they are useful in GCC generally and thus should be made available in the proper generic places (not gimple-match-head.c), like for example in tree.[ch]. Note that code-generation should be changed to delay testing of predicates until the if-expression is processed. That is, predicates are really just a "shortcut" for capturing the operand and testing the predicate in the if-expr. The idea here is that matching the whole structure of the expression is cheap while testing predicates is not. So I don't think we want any define-predicate stuff in the language. Richard. > Thanks, > Prathamesh
Could you please clarify about GCC optimizations?
Dear GCC Developers! May I ask you regarding how you make a decision whether implement some optimization or not? As far as I know, there are so many configurations (frontends x backends x applications(benchmarks) x etc), that the same optimization could improve performance in one configuration and degrade at other conditions. What performance tests do you perform before including an optimization in GCC? How do you aggregate the results (taking into account different behavior on different frontend/backend/benchmarks)? Excuse me, if some information is available in GCC documentation, didn’t found so far. Thank you! Evgeniya
GIMPLE optimization passes: any Road Map?
Dear GCC Developers! Could you please clarify about GIMPLE loop passes? Where could I find the latest changes in these passes? Is it trunk or some of the branches? May I look at some RoadMap on GIMPLE loop optimizations? Actually, I ask these questions because I would like to contribute to GCC. GIMPLE optimizations would be interesting to me (in particular, loop optimizations). However, I’m newbie at GCC and have not enough time, so would not commit to manage a task which is on the critical path. So it would be great if you could advise some tasks, which could be useful to gcc in some future, however nobody will miss if I can’t do it (as you had not time/people for these tasks anyway :) ). Thank you! Evgeniya m
-x assembler-with-cpp behavior different on different unixes.
Hello,
GHC (Haskell compiler) is using builtin gcc's cpp for its cpp
capability. The problem is a little bit different behaviour on
different platform which I observed. As one of GHC's testcases
completely unrelated to gcc's cpp we use:
{-# LANGUAGE CPP #-}
module T7145b ( A.Applicative(pure) ) where
import qualified Control.Applicative as A
pure :: ()
pure = ()
now, internally GHC calls GCC's cpp on this file with some -Is and
following options (-I removed for brevity):
/usr/bin/gcc -E -undef -traditional '-D__GLASGOW_HASKELL__=709'
'-Dsolaris2_BUILD_OS=1' '-Di386_BUILD_ARCH=1' '-Dsolaris2_HOST_OS=1'
'-Di386_HOST_ARCH=1' -x assembler-with-cpp T7145b.hs -o
/tmp/ghc2662_0/ghc2662_1.hscpp
the problem is that produced code looks:
{-# LANGUAGE CPP #-}
module T7145b ( A.Applicative(pure) ) where
import qualified Control.Applicative as A
pure :: ()
pure = ()
so exact copy of the input file. Now, this is with Solaris 11.1
distributed GNU C 4.5.2. I've tested also 4.6.0, 4.7.1 and 4.8.2 built
by myself on the same platform and all those exhibit the same
behaviour.
Now, if I try the same on Ubuntu 14.04 LTS which provides GNU C 4.8.2,
then I get the expected output which contains
# 1 "T7145b.hs"
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 17 "/usr/include/stdc-predef.h" 3 4
[ empty lines cut]
# 1 "" 2
# 1 "T7145b.hs"
{-# LANGUAGE CPP #-}
module T7145b ( A.Applicative(pure) ) where
import qualified Control.Applicative as A
pure :: ()
pure = ()
Now my question is what exactly is expected behaviour and what not.
I'm mainly interested in this # 1 "7145b.hs" since we need it to get
the source file name right in following GHC emitted warning/error
messages. Is there any way how to enable those CPP marks even on
Solaris? Or is Ubuntu using some distro specific patch to enable this
behaviour and the behaviour itself is deprecated?
Thanks!
Karel
Re: Could you please clarify about GCC optimizations?
On 08/08/14 06:18, Evgeniya Maenkova wrote: As far as I know, there are so many configurations (frontends x backends x applications(benchmarks) x etc), that the same optimization could improve performance in one configuration and degrade at other conditions. Correct. What performance tests do you perform before including an optimization in GCC? How do you aggregate the results (taking into account different behavior on different frontend/backend/benchmarks)? Excuse me, if some information is available in GCC documentation, didn’t found so far. Each developer makes their own determination as to what performance tests are appropriate to run and on what platforms to run those tests. Some rely largely on SPEC, others utilize large desktop applications such as firefox and others are more focused on EEMBC, etc. It really depends on each developer's focus. In general optimizations on GIMPLE/SSA are in large designed to eliminate as much redundancy as possible independent of the target processor. There are exceptions, but as a guiding principle that is correct. When GIMPLE is lowered to RTL, the expanders query the backend for a information to guide lowering to RTL in a target dependent way. Similarly the RTL optimizers are designed to query the backend for information to guide low level aspects of code generation and optimization. When optimizations are submitted for inclusion, there's a review process where the code reviewers may ask questions or ask for further benchmarks, etc. The reviewers also use their experience to guide submissions in the right direction. So there's no single simple answer. It varies based on many factors. jeff
Re: -x assembler-with-cpp behavior different on different unixes.
More information: It looks like gcc driver invokes cc1 with -P option
which switches off linemakers on Solaris. On Linux cc1 is invoked
without -P and so linemakers are presented. The question is why on
Solaris -P is added to the options since I don't use it myself. It's
inserted by gcc itself...
Thanks,
Karel
On Fri, Aug 8, 2014 at 8:47 PM, Karel Gardas wrote:
> Hello,
>
> GHC (Haskell compiler) is using builtin gcc's cpp for its cpp
> capability. The problem is a little bit different behaviour on
> different platform which I observed. As one of GHC's testcases
> completely unrelated to gcc's cpp we use:
>
> {-# LANGUAGE CPP #-}
> module T7145b ( A.Applicative(pure) ) where
>
> import qualified Control.Applicative as A
>
> pure :: ()
> pure = ()
>
>
> now, internally GHC calls GCC's cpp on this file with some -Is and
> following options (-I removed for brevity):
> /usr/bin/gcc -E -undef -traditional '-D__GLASGOW_HASKELL__=709'
> '-Dsolaris2_BUILD_OS=1' '-Di386_BUILD_ARCH=1' '-Dsolaris2_HOST_OS=1'
> '-Di386_HOST_ARCH=1' -x assembler-with-cpp T7145b.hs -o
> /tmp/ghc2662_0/ghc2662_1.hscpp
>
> the problem is that produced code looks:
>
> {-# LANGUAGE CPP #-}
> module T7145b ( A.Applicative(pure) ) where
>
> import qualified Control.Applicative as A
>
> pure :: ()
> pure = ()
>
>
> so exact copy of the input file. Now, this is with Solaris 11.1
> distributed GNU C 4.5.2. I've tested also 4.6.0, 4.7.1 and 4.8.2 built
> by myself on the same platform and all those exhibit the same
> behaviour.
>
> Now, if I try the same on Ubuntu 14.04 LTS which provides GNU C 4.8.2,
> then I get the expected output which contains
>
> # 1 "T7145b.hs"
> # 1 ""
> # 1 "/usr/include/stdc-predef.h" 1 3 4
>
> # 17 "/usr/include/stdc-predef.h" 3 4
> [ empty lines cut]
> # 1 "" 2
> # 1 "T7145b.hs"
> {-# LANGUAGE CPP #-}
> module T7145b ( A.Applicative(pure) ) where
>
> import qualified Control.Applicative as A
>
> pure :: ()
> pure = ()
>
> Now my question is what exactly is expected behaviour and what not.
> I'm mainly interested in this # 1 "7145b.hs" since we need it to get
> the source file name right in following GHC emitted warning/error
> messages. Is there any way how to enable those CPP marks even on
> Solaris? Or is Ubuntu using some distro specific patch to enable this
> behaviour and the behaviour itself is deprecated?
>
> Thanks!
>
> Karel
Re: -x assembler-with-cpp behavior different on different unixes.
Hi Karel,
> More information: It looks like gcc driver invokes cc1 with -P option
> which switches off linemakers on Solaris. On Linux cc1 is invoked
> without -P and so linemakers are presented. The question is why on
> Solaris -P is added to the options since I don't use it myself. It's
> inserted by gcc itself...
you can find this explained in gcc/config/i386/sol2.h (so this
behaviour is Solaris/x86-specific):
/* Solaris 2/Intel as chokes on #line directives before Solaris 10. */
#undef CPP_SPEC
#define CPP_SPEC "%{,assembler-with-cpp:-P} %(cpp_subtarget)"
With Solaris 9 support gone on mainline, this can be revisited now, but
this won't change anything for released versions.
Apart from that, why are you invoking gcc with -x assembler-with-cpp
when the input is clearly anything but assembler input? You're
obviously lying to the compiler, and I'd go as far as claiming that you
get what you deserve: garbage in, garbage out.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: -x assembler-with-cpp behavior different on different unixes.
Hi Rainer,
On Fri, Aug 8, 2014 at 11:04 PM, Rainer Orth
wrote:
> Hi Karel,
>
>> More information: It looks like gcc driver invokes cc1 with -P option
>> which switches off linemakers on Solaris. On Linux cc1 is invoked
>> without -P and so linemakers are presented. The question is why on
>> Solaris -P is added to the options since I don't use it myself. It's
>> inserted by gcc itself...
>
> you can find this explained in gcc/config/i386/sol2.h (so this
> behaviour is Solaris/x86-specific):
>
> /* Solaris 2/Intel as chokes on #line directives before Solaris 10. */
> #undef CPP_SPEC
> #define CPP_SPEC "%{,assembler-with-cpp:-P} %(cpp_subtarget)"
Thanks a lot for this reference! Hmm, I see I can't do with this
anything since I'd like to use as much as possible Solaris bundled GNU
C.
> With Solaris 9 support gone on mainline, this can be revisited now, but
> this won't change anything for released versions.
What shall I do for this to be at least considered?
> Apart from that, why are you invoking gcc with -x assembler-with-cpp
> when the input is clearly anything but assembler input? You're
> obviously lying to the compiler, and I'd go as far as claiming that you
> get what you deserve: garbage in, garbage out.
>
:-) fair enough, but GHC requires to use some CPP and GNU C's provided
one is very comfortable. Well, at least except on Solaris as you
see...
Thanks a lot for your help!
Karel
Re: -x assembler-with-cpp behavior different on different unixes.
Hi Karel,
> On Fri, Aug 8, 2014 at 11:04 PM, Rainer Orth
> wrote:
>> Hi Karel,
>>
>>> More information: It looks like gcc driver invokes cc1 with -P option
>>> which switches off linemakers on Solaris. On Linux cc1 is invoked
>>> without -P and so linemakers are presented. The question is why on
>>> Solaris -P is added to the options since I don't use it myself. It's
>>> inserted by gcc itself...
>>
>> you can find this explained in gcc/config/i386/sol2.h (so this
>> behaviour is Solaris/x86-specific):
>>
>> /* Solaris 2/Intel as chokes on #line directives before Solaris 10. */
>> #undef CPP_SPEC
>> #define CPP_SPEC "%{,assembler-with-cpp:-P} %(cpp_subtarget)"
>
> Thanks a lot for this reference! Hmm, I see I can't do with this
> anything since I'd like to use as much as possible Solaris bundled GNU
> C.
right, and even if you wanted to build gcc yourself, you'd need to patch
it, which does no good for anyone else trying to build/test ghc.
>> With Solaris 9 support gone on mainline, this can be revisited now, but
>> this won't change anything for released versions.
>
> What shall I do for this to be at least considered?
Nothing: it's already on my agenda to fix this for 4.10/5.0, thanks to
your report :-) The only thing one could possibly do for older releases
is to restrict passing -P to Sun as, but given the niche case that
triggers this, this is almost certainly too invasive for a micro
release.
>> Apart from that, why are you invoking gcc with -x assembler-with-cpp
>> when the input is clearly anything but assembler input? You're
>> obviously lying to the compiler, and I'd go as far as claiming that you
>> get what you deserve: garbage in, garbage out.
>
> :-) fair enough, but GHC requires to use some CPP and GNU C's provided
> one is very comfortable. Well, at least except on Solaris as you
> see...
But why the -x assembler-with-cpp instead of plain -E? Besides, this is
another example of why cpp is not really suited as a general-purpose
preprocessor.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
