RE: SC: New MIPS maintainers needed
Eric Christopher writes: > On Tue, Jul 29, 2014 at 5:58 AM, Matthew Fortune > wrote: > > Jeff Law writes: > >> On 07/22/14 06:56, Richard Sandiford wrote: > >> > I'll need to step down as MIPS maintainer this weekend in order to > >> avoid > >> > a possible conflict of interest with a new job. SC: please could you > >> > appoint some new maintainers to take over? > >> We'll get the process started. > >> > >> Stepping down doesn't require you do do anything further than removing > >> yourself as the listed maintainer for the MIPS port > > > > Hi Richard, > > > > Although I've only worked with you for a relatively short time I'd like > > to thank you for all the help and guidance you have given. I'm sure the > > MIPS community owes much to your stewardship over the years and I'm > > certain that it has been appreciated. > > > > Jeff: > > > > Now that Richard has stood down as the MIPS maintainer can you > > advise on the process for getting patches approved? Should we cc > > any particular global maintainer or just post and allow someone to get > > to it when they can? > > > > You can technically cc me on it, I've not been able to do a lot of > work with gcc until recently, but I am now reading the list etc. Patch > review will take a bit longer than Richard, he's very hard to replace. My apologies, I knew you were a named MIPS maintainer but didn't know you were able to work on the codebase again. > I'm also down with you and Catherine being nominated for > maintainership, you've both been doing a lot of work in the area and > it makes some sense. Thanks, Matthew
Re: Prototype of a --report-bug option
On Tue, Jul 29, 2014 at 8:35 PM, David Malcolm wrote: > At Cauldron on the Sunday morning there was a Release Management BoF > session, replacing the specRTL talk (does anyone know what happened to > the latter?) > > One of the topics was bug triage, and how many bug reports lacked basic > metadata on e.g. host/build/target, reproducer etc. > > I suggested we could automate gathering this, and rashly promised to > write a prototype in Python. So here it is... > > The attached script demonstrates a way to generate a URL that, when > followed, takes the user to the GCC Bugzilla "Enter Bug" page, with all > pertinent fields prepopulated with meaningful data. (run the script, > and follow the URL; this uses the same server-side URLs as the "Remember > values as bookmarkable template" BZ button). > > The idea is that the "gcc" driver program could gain a --report-bug > feature that injects -save-temps into the options, disables plugins, and > tries to reproduce a crash. It then gives you the URL to click on, > capturing the backtrace and embedding it into the form for you. > > Perhaps we could guess the "Component" based on the backtrace. > > I note that there doesn't seem to be a "trunk" entry for "Version". > > I am both proud of, and scared of, this idea: it could make it easy for > people to file higher-quality bugs. On the other hand, that means more > bugs in the tracker... (they do at least need to be logged in). > > Note that this points users at the GCC bug tracker. Presumably > downstream packagers of GCC may want to customize such a feature to > point at their bug trackers (e.g. at Red Hat we have our own bugzilla > instance, with a different set of custom fields). Heh... I was hoping this would be a patch to the driver directly (thus not a python script). Note that I don't care too much about the reproducing/-save-temps and backtrace for the driver option. Of course in case of an ICE producing a proper bug-url with the backtrace info included would even be better. Richard. > Thoughts? > Dave
Re: writing patterns
On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni wrote: > Hi, >Sorry to ask a stupid question, but I am having issues writing patterns > involving casts. I am trying to write patterns from simplify_rotate. > > Could you show me how to write a patterns that involve > casts ? > for eg: > ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B > T -> some unsigned type with bitsize B, and some type T2 wider than T. > How to express this in the pattern ? [copying gcc@ because of the syntax stuff] for example with (leaving captures as the appear in the pattern above) (match_and_simplify (plus (convert@2 (lshift (convert@0 X) CNT1)) (convert (rshift (convert@1 X) CNT2))) /* Types T2 have to match */ (if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) /* Type T should be unsigned. */ && TYPE_UNSIGNED (TREE_TYPE (@2)) /* T2 should be wider than T. */ && TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) /* CNT1 + CNT2 == B */ && wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), wi::add (CNT1, CNT2 (lrotate CNT1)) which suggests that we may want to add some type capturing / matching so we can maybe write (plus (convert@T (lshift (convert@T2 X) CNT1)) (convert (rshift (convert@T2 X) CNT2))) (if (/* T2s will be matched automagically */ && TYPE_UNSIGNED (@T) && TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) && wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 which is less to type and supports requiring matching types. Maybe require @T[0-9]+ here thus use @T0 and disallow plain @T. We could then also use @T for the implicitely "captured" outermost type we refer to as plain 'type' right now. I suggest to go ahead without a new syntax for now and see if it gets unwieldingly ugly without first. > For this week, I have planned: > a) writing patterns from simplify_rotate > b) replacing op in c_expr > c) writing more test-cases. > > If there's anything else you would like me to do, I would be happy > to know. Just keep an eye open for things like above - easy ways to reduce typing for patterns. Btw, I suggest to split up match.pd by code you converted from. Thus for simplify_rotate add match-simplify-rotate.pd with the patterns and do a #include "match-simplify-rotate.pd" in match.pd. That will make it easier to match the two later. Thanks, Richard. > Thanks, > Prathamesh
Re: writing patterns
On Wed, Jul 30, 2014 at 1:11 PM, Richard Biener wrote: > On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni > wrote: >> Hi, >>Sorry to ask a stupid question, but I am having issues writing patterns >> involving casts. I am trying to write patterns from simplify_rotate. >> >> Could you show me how to write a patterns that involve >> casts ? >> for eg: >> ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B >> T -> some unsigned type with bitsize B, and some type T2 wider than T. >> How to express this in the pattern ? > > [copying gcc@ because of the syntax stuff] > > for example with (leaving captures as the appear in the pattern above) > > (match_and_simplify >(plus (convert@2 (lshift (convert@0 X) CNT1)) >(convert (rshift (convert@1 X) CNT2))) > /* Types T2 have to match */ >(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) > /* Type T should be unsigned. */ >&& TYPE_UNSIGNED (TREE_TYPE (@2)) >/* T2 should be wider than T. */ >&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >/* CNT1 + CNT2 == B */ >&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >wi::add (CNT1, CNT2 >(lrotate CNT1)) Note that this will _explicitely_ require a conversion. That is, if T == T2 it won't match because the conversion to T will not be there, nor if X is already of type T2. Which means that we want to match multiple variants of this (with conversions in place or not). Hmm. Maybe with extending 'for' like (for cvt1 in convert * (fot cvt2 in convert * (plus@2 (cvt1 (lshift@0 (cvt2 X) CNT1)) (cvt1 (rshift@1 (cvt2 X) CNT2))) ... adding an "empty" operator to the list of operators to substitute for cvt1 and allowing nested for. The "empty" operator would necessarily be unary and be just un-wrapped. Extending for in this way avoids treating conversions specially (I don't see an easy way to do very good at that automagically). We need multiple patterns in the decision tree here anyway. Now guess sth fancy in place of '*' ... Lisp style would be less free-form like (for cvt (convert ()) where we could use an empty list for the "empty" operator. Is nested for support already implemented? Thanks, Richard. > which suggests that we may want to add some type capturing / matching > so we can maybe write > > (plus (convert@T (lshift (convert@T2 X) CNT1)) > (convert (rshift (convert@T2 X) CNT2))) > (if (/* T2s will be matched automagically */ >&& TYPE_UNSIGNED (@T) >&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 > > which is less to type and supports requiring matching types. Maybe > require @T[0-9]+ here thus use @T0 and disallow plain @T. We could > then also use @T for the implicitely "captured" outermost type we > refer to as plain 'type' right now. > > I suggest to go ahead without a new syntax for now and see if it > gets unwieldingly ugly without first. > >> For this week, I have planned: >> a) writing patterns from simplify_rotate >> b) replacing op in c_expr >> c) writing more test-cases. >> >> If there's anything else you would like me to do, I would be happy >> to know. > > Just keep an eye open for things like above - easy ways to reduce > typing for patterns. > > Btw, I suggest to split up match.pd by code you converted from. Thus > for simplify_rotate add > > match-simplify-rotate.pd > > with the patterns and do a #include "match-simplify-rotate.pd" > in match.pd. That will make it easier to match the two later. > > Thanks, > Richard. > > >> Thanks, >> Prathamesh
Re: writing patterns
On Wed, Jul 30, 2014 at 4:41 PM, Richard Biener wrote: > On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni > wrote: >> Hi, >>Sorry to ask a stupid question, but I am having issues writing patterns >> involving casts. I am trying to write patterns from simplify_rotate. >> >> Could you show me how to write a patterns that involve >> casts ? >> for eg: >> ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B >> T -> some unsigned type with bitsize B, and some type T2 wider than T. >> How to express this in the pattern ? > > [copying gcc@ because of the syntax stuff] > > for example with (leaving captures as the appear in the pattern above) > > (match_and_simplify >(plus (convert@2 (lshift (convert@0 X) CNT1)) >(convert (rshift (convert@1 X) CNT2))) > /* Types T2 have to match */ >(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) > /* Type T should be unsigned. */ >&& TYPE_UNSIGNED (TREE_TYPE (@2)) >/* T2 should be wider than T. */ >&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >/* CNT1 + CNT2 == B */ >&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >wi::add (CNT1, CNT2 >(lrotate CNT1)) > > which suggests that we may want to add some type capturing / matching > so we can maybe write > > (plus (convert@T (lshift (convert@T2 X) CNT1)) > (convert (rshift (convert@T2 X) CNT2))) > (if (/* T2s will be matched automagically */ >&& TYPE_UNSIGNED (@T) >&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 > Thanks. > which is less to type and supports requiring matching types. Maybe > require @T[0-9]+ here thus use @T0 and disallow plain @T. We could > then also use @T for the implicitely "captured" outermost type we > refer to as plain 'type' right now. What if we need to capture "value" as well as "type" ? for instance match type with another capture, and value with a different capture ? sth like: (bogus pattern): (match_and_simplify (plus (minus@T@2 @0 @1) (mult@T @2 @3)) transform) > I suggest to go ahead without a new syntax for now and see if it > gets unwieldingly ugly without first. > >> For this week, I have planned: >> a) writing patterns from simplify_rotate >> b) replacing op in c_expr >> c) writing more test-cases. >> >> If there's anything else you would like me to do, I would be happy >> to know. > > Just keep an eye open for things like above - easy ways to reduce > typing for patterns. > > Btw, I suggest to split up match.pd by code you converted from. Thus > for simplify_rotate add > > match-simplify-rotate.pd > > with the patterns and do a #include "match-simplify-rotate.pd" > in match.pd. That will make it easier to match the two later. Okay, should I correspondingly split bitwise patterns in match-simplify-bitwise.pd and the rest ? Thanks, Prathamesh > > Thanks, > Richard. > > >> Thanks, >> Prathamesh
Re: writing patterns
On Wed, Jul 30, 2014 at 4:49 PM, Richard Biener wrote: > On Wed, Jul 30, 2014 at 1:11 PM, Richard Biener > wrote: >> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >> wrote: >>> Hi, >>>Sorry to ask a stupid question, but I am having issues writing patterns >>> involving casts. I am trying to write patterns from simplify_rotate. >>> >>> Could you show me how to write a patterns that involve >>> casts ? >>> for eg: >>> ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B >>> T -> some unsigned type with bitsize B, and some type T2 wider than T. >>> How to express this in the pattern ? >> >> [copying gcc@ because of the syntax stuff] >> >> for example with (leaving captures as the appear in the pattern above) >> >> (match_and_simplify >>(plus (convert@2 (lshift (convert@0 X) CNT1)) >>(convert (rshift (convert@1 X) CNT2))) >> /* Types T2 have to match */ >>(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) >> /* Type T should be unsigned. */ >>&& TYPE_UNSIGNED (TREE_TYPE (@2)) >>/* T2 should be wider than T. */ >>&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >>/* CNT1 + CNT2 == B */ >>&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >>wi::add (CNT1, CNT2 >>(lrotate CNT1)) > > Note that this will _explicitely_ require a conversion. That is, if T == T2 > it won't match because the conversion to T will not be there, nor if X > is already of type T2. > > Which means that we want to match multiple variants of this > (with conversions in place or not). Hmm. Maybe with extending 'for' like > > (for cvt1 in convert * > (fot cvt2 in convert * > (plus@2 (cvt1 (lshift@0 (cvt2 X) CNT1)) > (cvt1 (rshift@1 (cvt2 X) CNT2))) > ... > > adding an "empty" operator to the list of operators to substitute for cvt1 > and allowing nested for. The "empty" operator would necessarily be > unary and be just un-wrapped. um can't we use nop for "empty" operator ? > > Extending for in this way avoids treating conversions specially > (I don't see an easy way to do very good at that automagically). We > need multiple patterns in the decision tree here anyway. > > Now guess sth fancy in place of '*' ... > > Lisp style would be less free-form like > > (for cvt (convert ()) > > where we could use an empty list for the "empty" operator. > > Is nested for support already implemented? Yes. Thanks, Prathamesh > > Thanks, > Richard. > >> which suggests that we may want to add some type capturing / matching >> so we can maybe write >> >> (plus (convert@T (lshift (convert@T2 X) CNT1)) >> (convert (rshift (convert@T2 X) CNT2))) >> (if (/* T2s will be matched automagically */ >>&& TYPE_UNSIGNED (@T) >>&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >>&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 >> >> which is less to type and supports requiring matching types. Maybe >> require @T[0-9]+ here thus use @T0 and disallow plain @T. We could >> then also use @T for the implicitely "captured" outermost type we >> refer to as plain 'type' right now. >> >> I suggest to go ahead without a new syntax for now and see if it >> gets unwieldingly ugly without first. >> >>> For this week, I have planned: >>> a) writing patterns from simplify_rotate >>> b) replacing op in c_expr >>> c) writing more test-cases. >>> >>> If there's anything else you would like me to do, I would be happy >>> to know. >> >> Just keep an eye open for things like above - easy ways to reduce >> typing for patterns. >> >> Btw, I suggest to split up match.pd by code you converted from. Thus >> for simplify_rotate add >> >> match-simplify-rotate.pd >> >> with the patterns and do a #include "match-simplify-rotate.pd" >> in match.pd. That will make it easier to match the two later. >> >> Thanks, >> Richard. >> >> >>> Thanks, >>> Prathamesh
Re: writing patterns
On Wed, Jul 30, 2014 at 5:55 PM, Prathamesh Kulkarni wrote: > On Wed, Jul 30, 2014 at 4:41 PM, Richard Biener > wrote: >> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >> wrote: >>> Hi, >>>Sorry to ask a stupid question, but I am having issues writing patterns >>> involving casts. I am trying to write patterns from simplify_rotate. >>> >>> Could you show me how to write a patterns that involve >>> casts ? >>> for eg: >>> ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B >>> T -> some unsigned type with bitsize B, and some type T2 wider than T. >>> How to express this in the pattern ? >> >> [copying gcc@ because of the syntax stuff] >> >> for example with (leaving captures as the appear in the pattern above) >> >> (match_and_simplify >>(plus (convert@2 (lshift (convert@0 X) CNT1)) >>(convert (rshift (convert@1 X) CNT2))) >> /* Types T2 have to match */ >>(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) >> /* Type T should be unsigned. */ >>&& TYPE_UNSIGNED (TREE_TYPE (@2)) >>/* T2 should be wider than T. */ >>&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >>/* CNT1 + CNT2 == B */ >>&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >>wi::add (CNT1, CNT2 >>(lrotate CNT1)) >> >> which suggests that we may want to add some type capturing / matching >> so we can maybe write >> >> (plus (convert@T (lshift (convert@T2 X) CNT1)) >> (convert (rshift (convert@T2 X) CNT2))) >> (if (/* T2s will be matched automagically */ >>&& TYPE_UNSIGNED (@T) >>&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >>&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 >> > Thanks. >> which is less to type and supports requiring matching types. Maybe >> require @T[0-9]+ here thus use @T0 and disallow plain @T. We could >> then also use @T for the implicitely "captured" outermost type we >> refer to as plain 'type' right now. > What if we need to capture "value" as well as "type" ? > for instance match type with another capture, and value with a > different capture ? > > sth like: (bogus pattern): > (match_and_simplify > (plus (minus@T@2 @0 @1) (mult@T @2 @3)) > transform) oops, @T was meant for outermost expression. sth like: (plus (minus@T0@2 @0 @1) (mult@T0 @2 @3)) however this doesn't look good. > >> I suggest to go ahead without a new syntax for now and see if it >> gets unwieldingly ugly without first. >> >>> For this week, I have planned: >>> a) writing patterns from simplify_rotate >>> b) replacing op in c_expr >>> c) writing more test-cases. >>> >>> If there's anything else you would like me to do, I would be happy >>> to know. >> >> Just keep an eye open for things like above - easy ways to reduce >> typing for patterns. >> >> Btw, I suggest to split up match.pd by code you converted from. Thus >> for simplify_rotate add >> >> match-simplify-rotate.pd >> >> with the patterns and do a #include "match-simplify-rotate.pd" >> in match.pd. That will make it easier to match the two later. > Okay, should I correspondingly split bitwise patterns in > match-simplify-bitwise.pd and the rest ? > > Thanks, > Prathamesh > >> >> Thanks, >> Richard. >> >> >>> Thanks, >>> Prathamesh
Re: writing patterns
On Wed, Jul 30, 2014 at 2:30 PM, Prathamesh Kulkarni wrote: > On Wed, Jul 30, 2014 at 5:55 PM, Prathamesh Kulkarni > wrote: >> On Wed, Jul 30, 2014 at 4:41 PM, Richard Biener >> wrote: >>> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >>> wrote: Hi, Sorry to ask a stupid question, but I am having issues writing patterns involving casts. I am trying to write patterns from simplify_rotate. Could you show me how to write a patterns that involve casts ? for eg: ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B T -> some unsigned type with bitsize B, and some type T2 wider than T. How to express this in the pattern ? >>> >>> [copying gcc@ because of the syntax stuff] >>> >>> for example with (leaving captures as the appear in the pattern above) >>> >>> (match_and_simplify >>>(plus (convert@2 (lshift (convert@0 X) CNT1)) >>>(convert (rshift (convert@1 X) CNT2))) >>> /* Types T2 have to match */ >>>(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) >>> /* Type T should be unsigned. */ >>>&& TYPE_UNSIGNED (TREE_TYPE (@2)) >>>/* T2 should be wider than T. */ >>>&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >>>/* CNT1 + CNT2 == B */ >>>&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >>>wi::add (CNT1, CNT2 >>>(lrotate CNT1)) >>> >>> which suggests that we may want to add some type capturing / matching >>> so we can maybe write >>> >>> (plus (convert@T (lshift (convert@T2 X) CNT1)) >>> (convert (rshift (convert@T2 X) CNT2))) >>> (if (/* T2s will be matched automagically */ >>>&& TYPE_UNSIGNED (@T) >>>&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >>>&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 >>> >> Thanks. >>> which is less to type and supports requiring matching types. Maybe >>> require @T[0-9]+ here thus use @T0 and disallow plain @T. We could >>> then also use @T for the implicitely "captured" outermost type we >>> refer to as plain 'type' right now. >> What if we need to capture "value" as well as "type" ? >> for instance match type with another capture, and value with a >> different capture ? >> >> sth like: (bogus pattern): >> (match_and_simplify >> (plus (minus@T@2 @0 @1) (mult@T @2 @3)) >> transform) > oops, @T was meant for outermost expression. > sth like: (plus (minus@T0@2 @0 @1) (mult@T0 @2 @3)) > however this doesn't look good. Yeah... well. I don't see very many compelling reasons for this kind of cross-match but didn't think of the matching case initially (otherwise capturing an expression is a "super-set" of capturing its type as you can get at its type with TREE_TYPE (@0)). I guess we can add support when need arises. Richard. >> >>> I suggest to go ahead without a new syntax for now and see if it >>> gets unwieldingly ugly without first. >>> For this week, I have planned: a) writing patterns from simplify_rotate b) replacing op in c_expr c) writing more test-cases. If there's anything else you would like me to do, I would be happy to know. >>> >>> Just keep an eye open for things like above - easy ways to reduce >>> typing for patterns. >>> >>> Btw, I suggest to split up match.pd by code you converted from. Thus >>> for simplify_rotate add >>> >>> match-simplify-rotate.pd >>> >>> with the patterns and do a #include "match-simplify-rotate.pd" >>> in match.pd. That will make it easier to match the two later. >> Okay, should I correspondingly split bitwise patterns in >> match-simplify-bitwise.pd and the rest ? >> >> Thanks, >> Prathamesh >> >>> >>> Thanks, >>> Richard. >>> >>> Thanks, Prathamesh
Re: writing patterns
On Wed, Jul 30, 2014 at 2:25 PM, Prathamesh Kulkarni wrote: > On Wed, Jul 30, 2014 at 4:49 PM, Richard Biener > wrote: >> On Wed, Jul 30, 2014 at 1:11 PM, Richard Biener >> wrote: >>> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >>> wrote: Hi, Sorry to ask a stupid question, but I am having issues writing patterns involving casts. I am trying to write patterns from simplify_rotate. Could you show me how to write a patterns that involve casts ? for eg: ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B T -> some unsigned type with bitsize B, and some type T2 wider than T. How to express this in the pattern ? >>> >>> [copying gcc@ because of the syntax stuff] >>> >>> for example with (leaving captures as the appear in the pattern above) >>> >>> (match_and_simplify >>>(plus (convert@2 (lshift (convert@0 X) CNT1)) >>>(convert (rshift (convert@1 X) CNT2))) >>> /* Types T2 have to match */ >>>(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) >>> /* Type T should be unsigned. */ >>>&& TYPE_UNSIGNED (TREE_TYPE (@2)) >>>/* T2 should be wider than T. */ >>>&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >>>/* CNT1 + CNT2 == B */ >>>&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >>>wi::add (CNT1, CNT2 >>>(lrotate CNT1)) >> >> Note that this will _explicitely_ require a conversion. That is, if T == T2 >> it won't match because the conversion to T will not be there, nor if X >> is already of type T2. >> >> Which means that we want to match multiple variants of this >> (with conversions in place or not). Hmm. Maybe with extending 'for' like >> >> (for cvt1 in convert * >> (fot cvt2 in convert * >> (plus@2 (cvt1 (lshift@0 (cvt2 X) CNT1)) >> (cvt1 (rshift@1 (cvt2 X) CNT2))) >> ... >> >> adding an "empty" operator to the list of operators to substitute for cvt1 >> and allowing nested for. The "empty" operator would necessarily be >> unary and be just un-wrapped. > um can't we use nop for "empty" operator ? Unfortunately "nop" is already taken (NOP_EXPR). we could use "nil". >> >> Extending for in this way avoids treating conversions specially >> (I don't see an easy way to do very good at that automagically). We >> need multiple patterns in the decision tree here anyway. >> >> Now guess sth fancy in place of '*' ... >> >> Lisp style would be less free-form like >> >> (for cvt (convert ()) >> >> where we could use an empty list for the "empty" operator. >> >> Is nested for support already implemented? > Yes. Great. Thanks, Richard. > Thanks, > Prathamesh >> >> Thanks, >> Richard. >> >>> which suggests that we may want to add some type capturing / matching >>> so we can maybe write >>> >>> (plus (convert@T (lshift (convert@T2 X) CNT1)) >>> (convert (rshift (convert@T2 X) CNT2))) >>> (if (/* T2s will be matched automagically */ >>>&& TYPE_UNSIGNED (@T) >>>&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >>>&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 >>> >>> which is less to type and supports requiring matching types. Maybe >>> require @T[0-9]+ here thus use @T0 and disallow plain @T. We could >>> then also use @T for the implicitely "captured" outermost type we >>> refer to as plain 'type' right now. >>> >>> I suggest to go ahead without a new syntax for now and see if it >>> gets unwieldingly ugly without first. >>> For this week, I have planned: a) writing patterns from simplify_rotate b) replacing op in c_expr c) writing more test-cases. If there's anything else you would like me to do, I would be happy to know. >>> >>> Just keep an eye open for things like above - easy ways to reduce >>> typing for patterns. >>> >>> Btw, I suggest to split up match.pd by code you converted from. Thus >>> for simplify_rotate add >>> >>> match-simplify-rotate.pd >>> >>> with the patterns and do a #include "match-simplify-rotate.pd" >>> in match.pd. That will make it easier to match the two later. >>> >>> Thanks, >>> Richard. >>> >>> Thanks, Prathamesh
Re: writing patterns
On Wed, Jul 30, 2014 at 2:25 PM, Prathamesh Kulkarni wrote: > On Wed, Jul 30, 2014 at 4:41 PM, Richard Biener > wrote: >> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >> wrote: >>> Hi, >>>Sorry to ask a stupid question, but I am having issues writing patterns >>> involving casts. I am trying to write patterns from simplify_rotate. >>> >>> Could you show me how to write a patterns that involve >>> casts ? >>> for eg: >>> ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B >>> T -> some unsigned type with bitsize B, and some type T2 wider than T. >>> How to express this in the pattern ? >> >> [copying gcc@ because of the syntax stuff] >> >> for example with (leaving captures as the appear in the pattern above) >> >> (match_and_simplify >>(plus (convert@2 (lshift (convert@0 X) CNT1)) >>(convert (rshift (convert@1 X) CNT2))) >> /* Types T2 have to match */ >>(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) >> /* Type T should be unsigned. */ >>&& TYPE_UNSIGNED (TREE_TYPE (@2)) >>/* T2 should be wider than T. */ >>&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >>/* CNT1 + CNT2 == B */ >>&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >>wi::add (CNT1, CNT2 >>(lrotate CNT1)) >> >> which suggests that we may want to add some type capturing / matching >> so we can maybe write >> >> (plus (convert@T (lshift (convert@T2 X) CNT1)) >> (convert (rshift (convert@T2 X) CNT2))) >> (if (/* T2s will be matched automagically */ >>&& TYPE_UNSIGNED (@T) >>&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >>&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 >> > Thanks. >> which is less to type and supports requiring matching types. Maybe >> require @T[0-9]+ here thus use @T0 and disallow plain @T. We could >> then also use @T for the implicitely "captured" outermost type we >> refer to as plain 'type' right now. > What if we need to capture "value" as well as "type" ? > for instance match type with another capture, and value with a > different capture ? > > sth like: (bogus pattern): > (match_and_simplify > (plus (minus@T@2 @0 @1) (mult@T @2 @3)) > transform) > >> I suggest to go ahead without a new syntax for now and see if it >> gets unwieldingly ugly without first. >> >>> For this week, I have planned: >>> a) writing patterns from simplify_rotate >>> b) replacing op in c_expr >>> c) writing more test-cases. >>> >>> If there's anything else you would like me to do, I would be happy >>> to know. >> >> Just keep an eye open for things like above - easy ways to reduce >> typing for patterns. >> >> Btw, I suggest to split up match.pd by code you converted from. Thus >> for simplify_rotate add >> >> match-simplify-rotate.pd >> >> with the patterns and do a #include "match-simplify-rotate.pd" >> in match.pd. That will make it easier to match the two later. > Okay, should I correspondingly split bitwise patterns in > match-simplify-bitwise.pd and the rest ? Yes, that would be nice. Richard. > Thanks, > Prathamesh > >> >> Thanks, >> Richard. >> >> >>> Thanks, >>> Prathamesh
Re: writing patterns
On Wed, Jul 30, 2014 at 6:44 PM, Richard Biener wrote: > On Wed, Jul 30, 2014 at 2:30 PM, Prathamesh Kulkarni > wrote: >> On Wed, Jul 30, 2014 at 5:55 PM, Prathamesh Kulkarni >> wrote: >>> On Wed, Jul 30, 2014 at 4:41 PM, Richard Biener >>> wrote: On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni wrote: > Hi, >Sorry to ask a stupid question, but I am having issues writing patterns > involving casts. I am trying to write patterns from simplify_rotate. > > Could you show me how to write a patterns that involve > casts ? > for eg: > ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B > T -> some unsigned type with bitsize B, and some type T2 wider than T. > How to express this in the pattern ? [copying gcc@ because of the syntax stuff] for example with (leaving captures as the appear in the pattern above) (match_and_simplify (plus (convert@2 (lshift (convert@0 X) CNT1)) (convert (rshift (convert@1 X) CNT2))) /* Types T2 have to match */ (if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) /* Type T should be unsigned. */ && TYPE_UNSIGNED (TREE_TYPE (@2)) /* T2 should be wider than T. */ && TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) /* CNT1 + CNT2 == B */ && wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), wi::add (CNT1, CNT2 (lrotate CNT1)) which suggests that we may want to add some type capturing / matching so we can maybe write (plus (convert@T (lshift (convert@T2 X) CNT1)) (convert (rshift (convert@T2 X) CNT2))) (if (/* T2s will be matched automagically */ && TYPE_UNSIGNED (@T) && TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) && wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 >>> Thanks. which is less to type and supports requiring matching types. Maybe require @T[0-9]+ here thus use @T0 and disallow plain @T. We could then also use @T for the implicitely "captured" outermost type we refer to as plain 'type' right now. >>> What if we need to capture "value" as well as "type" ? >>> for instance match type with another capture, and value with a >>> different capture ? >>> >>> sth like: (bogus pattern): >>> (match_and_simplify >>> (plus (minus@T@2 @0 @1) (mult@T @2 @3)) >>> transform) >> oops, @T was meant for outermost expression. >> sth like: (plus (minus@T0@2 @0 @1) (mult@T0 @2 @3)) >> however this doesn't look good. > > Yeah... well. I don't see very many compelling reasons for this > kind of cross-match but didn't think of the matching case initially > (otherwise capturing an expression is a "super-set" of capturing > its type as you can get at its type with TREE_TYPE (@0)). I was wondering if it would be a good idea to have "capture expressions" ? sth like: (plus (minus@2 @0 @1) (mult@(type @2) @2 @3)) (type @2) would only match type with the given catpure (@2), and not the whole thing. If we also need to capture mult-node, it would be written as: (plus (minus@2 @0 @1) (mult@4(type @2) @2 @3)) Thanks, Prathamesh > > I guess we can add support when need arises. > > Richard. > >>> I suggest to go ahead without a new syntax for now and see if it gets unwieldingly ugly without first. > For this week, I have planned: > a) writing patterns from simplify_rotate > b) replacing op in c_expr > c) writing more test-cases. > > If there's anything else you would like me to do, I would be happy > to know. Just keep an eye open for things like above - easy ways to reduce typing for patterns. Btw, I suggest to split up match.pd by code you converted from. Thus for simplify_rotate add match-simplify-rotate.pd with the patterns and do a #include "match-simplify-rotate.pd" in match.pd. That will make it easier to match the two later. >>> Okay, should I correspondingly split bitwise patterns in >>> match-simplify-bitwise.pd and the rest ? >>> >>> Thanks, >>> Prathamesh >>> Thanks, Richard. > Thanks, > Prathamesh
current NEON status
Hi there!
My question came from bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725. I found that GCC
considers NEON register ranges as unsplittable. So any subregister may
be used only after whole chunk is dead. This issue leads to redundant
spill fills which is performance trouble.
Example 1: RAL trouble
#include
#include
extern uint16x8x4_t m0;
extern uint16x8x4_t m1;
extern uint16x8x4_t m2;
extern uint16x8x4_t m3;
extern uint16x8_t m4;
void foo1(uint16_t * in_ptr)
{
uint16x8x4_t t0, t1, t2, t3;
t0 = vld4q_u16((uint16_t *)&in_ptr[0 ]);
t1 = vld4q_u16((uint16_t *)&in_ptr[64]);
t2 = vld4q_u16((uint16_t *)&in_ptr[128]);
t3 = vld4q_u16((uint16_t *)&in_ptr[192]);
m4 = t0.val[3];
m4 = m4 * 3; <<< *
t0.val[3] = t1.val[3];
m0 = t3;
m1 = t2;
m2 = t1;
m3 = t0;
}
Here test uses all NEON registers. No spill is needed. Because
multiplication requires one Q register which may be obtained from dead
t0.val[3] subregister. But GCC makes spill if multiplication (*) exists
because of issue described above.
Example 2: CSE makes trouble for IRA
#include
#include
extern uint16x8x4_t m0;
extern uint16x8x4_t m1;
void foo2(uint16_t * in_ptr)
{
uint16x8x4_t t0, t1;
t0 = vld4q_u16((uint16_t *)&in_ptr[0 ]);
t1 = vld4q_u16((uint16_t *)&in_ptr[64]);
t0.val[0] *= 333;
t0.val[1] *= 333;
t0.val[2] *= 333;
t0.val[3] *= 333;
t1.val[0] *= 333;
t1.val[1] *= 333;
t1.val[2] *= 333;
t1.val[3] *= 333;
m0 = t0;
m1 = t1;
}
Here test uses only half NEON + one Q for '333' factor. But GCC makes
spills here too! Briefly speak problem is in partial CSE. GCC generates
rtl with the listed bellow form:
Before CSE:
a = b
a0 = a0 * 3
a1 = a1 * 3
a2 = a2 * 3
a3 = a3 * 3
After:
a = b
a0 = b0 * 3
a1 = a1 * 3 <<< *
a2 = a2 * 3
a3 = a3 * 3
CSE do not substitute b1 to a1 because at the moment (*) a0 was already
defined so actually a != b. Yes but a1 = b1, unfortunately CSE also do
not handle register-ranges parts as RA does. Strange thing here is that
even if we fix CSE, so CSE could propagate register-ranges subregs, this
will make trouble to RAL also because of the same reason: IRA do not
handle precisely register ranges parts. I attached a demo patch which
forbids partial CSE propagation and removes spills from Ex2. Is this
patch OK? Or maybe CSE should be fixed in a different way? Or maybe
partial substitution is OK?
Main question: Are there any plans to fix/upgrade IRA?
--Marat
gcc/ChangeLog:
2014-07-30 Marat Zakirov
* cse.c (canon_reg): Forbid partial CSE.
* fwprop.c (forward_propagate_and_simplify): Likewise.
diff --git a/gcc/cse.c b/gcc/cse.c
index 34f9364..a9e0442 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -2862,6 +2862,9 @@ canon_reg (rtx x, rtx insn)
|| ! REGNO_QTY_VALID_P (REGNO (x)))
return x;
+if (GET_MODE (x) == XImode)
+ return x;
+
q = REG_QTY (REGNO (x));
ent = &qty_table[q];
first = ent->first_reg;
diff --git a/gcc/fwprop.c b/gcc/fwprop.c
index 547fcd6..eadc729 100644
--- a/gcc/fwprop.c
+++ b/gcc/fwprop.c
@@ -1317,6 +1317,9 @@ forward_propagate_and_simplify (df_ref use, rtx def_insn, rtx def_set)
if (!new_rtx)
return false;
+ if (GET_MODE (reg) == XImode)
+return false;
+
return try_fwprop_subst (use, loc, new_rtx, def_insn, set_reg_equal);
}
Re: writing patterns
On Wed, Jul 30, 2014 at 3:36 PM, Prathamesh Kulkarni wrote: > On Wed, Jul 30, 2014 at 6:44 PM, Richard Biener > wrote: >> On Wed, Jul 30, 2014 at 2:30 PM, Prathamesh Kulkarni >> wrote: >>> On Wed, Jul 30, 2014 at 5:55 PM, Prathamesh Kulkarni >>> wrote: On Wed, Jul 30, 2014 at 4:41 PM, Richard Biener wrote: > On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni > wrote: >> Hi, >>Sorry to ask a stupid question, but I am having issues writing >> patterns >> involving casts. I am trying to write patterns from simplify_rotate. >> >> Could you show me how to write a patterns that involve >> casts ? >> for eg: >> ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B >> T -> some unsigned type with bitsize B, and some type T2 wider than T. >> How to express this in the pattern ? > > [copying gcc@ because of the syntax stuff] > > for example with (leaving captures as the appear in the pattern above) > > (match_and_simplify >(plus (convert@2 (lshift (convert@0 X) CNT1)) >(convert (rshift (convert@1 X) CNT2))) > /* Types T2 have to match */ >(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) > /* Type T should be unsigned. */ >&& TYPE_UNSIGNED (TREE_TYPE (@2)) >/* T2 should be wider than T. */ >&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE > (@2)) >/* CNT1 + CNT2 == B */ >&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >wi::add (CNT1, CNT2 >(lrotate CNT1)) > > which suggests that we may want to add some type capturing / matching > so we can maybe write > > (plus (convert@T (lshift (convert@T2 X) CNT1)) > (convert (rshift (convert@T2 X) CNT2))) > (if (/* T2s will be matched automagically */ >&& TYPE_UNSIGNED (@T) >&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 > Thanks. > which is less to type and supports requiring matching types. Maybe > require @T[0-9]+ here thus use @T0 and disallow plain @T. We could > then also use @T for the implicitely "captured" outermost type we > refer to as plain 'type' right now. What if we need to capture "value" as well as "type" ? for instance match type with another capture, and value with a different capture ? sth like: (bogus pattern): (match_and_simplify (plus (minus@T@2 @0 @1) (mult@T @2 @3)) transform) >>> oops, @T was meant for outermost expression. >>> sth like: (plus (minus@T0@2 @0 @1) (mult@T0 @2 @3)) >>> however this doesn't look good. >> >> Yeah... well. I don't see very many compelling reasons for this >> kind of cross-match but didn't think of the matching case initially >> (otherwise capturing an expression is a "super-set" of capturing >> its type as you can get at its type with TREE_TYPE (@0)). > I was wondering if it would be a good idea to have "capture expressions" ? > sth like: > (plus (minus@2 @0 @1) (mult@(type @2) @2 @3)) > > (type @2) would only match type with the given catpure (@2), and not > the whole thing. > If we also need to capture mult-node, it would be written as: > (plus (minus@2 @0 @1) (mult@4(type @2) @2 @3)) Huh, that get's a bit too complicated for my taste ;) As always I want to see an actual pattern that would benefit a lot from this kind of new features. Richard. > > Thanks, > Prathamesh >> >> I guess we can add support when need arises. >> >> Richard. >> > I suggest to go ahead without a new syntax for now and see if it > gets unwieldingly ugly without first. > >> For this week, I have planned: >> a) writing patterns from simplify_rotate >> b) replacing op in c_expr >> c) writing more test-cases. >> >> If there's anything else you would like me to do, I would be happy >> to know. > > Just keep an eye open for things like above - easy ways to reduce > typing for patterns. > > Btw, I suggest to split up match.pd by code you converted from. Thus > for simplify_rotate add > > match-simplify-rotate.pd > > with the patterns and do a #include "match-simplify-rotate.pd" > in match.pd. That will make it easier to match the two later. Okay, should I correspondingly split bitwise patterns in match-simplify-bitwise.pd and the rest ? Thanks, Prathamesh > > Thanks, > Richard. > > >> Thanks, >> Prathamesh
Re: C as intermediate language, signed integer overflow and -ftrapv
On Jul 23, 2014, at 10:56 AM, Thomas Mertes wrote: > One such feature is the detection of signed integer overflow. It is > not hard, to detect signed integer overflow with a generated C > program, but the performance is certainly not optimal. Signed integer > overflow is undefined behavior in C and the access to some overflow > flag of the CPU is machine dependent. Actually, doing proper signed integer overflow checking in a front end can be surprisingly cheap. I have some experience with this for the Ada front end, and found the following: - In many cases it may be cheapest to widen computations to avoid overflow, and/or check it less frequently. - Even if you need to check, often one side is known to be constant, in which case a simple comparison of the input argument is sufficient - In other cases, the sign of one of the operands is known, simplifying the check - Conversions from signed to unsigned types is essentially free and well-defined, so do the overflow check using unsigned types, but use signed integer operations for the actual computation: - By using a simple comparison to jump to a no_return function, GCC knows the condition is expected to be false and will optimize accordingly Note that in the second case above, the extra conditional (which will almost always be correctly predicted by the CPU and often is free) will, combined with the conditional transfer of control to a no_return routine, in effect provide range information to the compiler, allowing the elimination of redundant checks etc. The positive effects of expanding checks to optimizable C-like constructs are far larger than the eventual instruction selection. We found the cost of overflow, even without "jo" instructions being generated, to be generally in the order of 1 - 2% in execution speed and a bit more in growth of executable size (in our case around 10% due to generating exceptions with location information). If you make overflow checking "special" early by resorting specific builtins, -ftrapv or similar, you'll lose out in the general purpose optimization passes and in my experience will get far worse code. If your language semantics are: provide the numerically correct answer (as if computed with unbounded range) or raise an exception, you can probably do better by using wider types and smart expansions to avoid overflow while retaining C-level intermediate code. Anyway, the Ada front end is proof that efficient overflow checking is possible without any special support in the back end. -Geert
Re: Prototype of a --report-bug option
On 07/30/2014 11:56 AM, Richard Biener wrote: On Tue, Jul 29, 2014 at 8:35 PM, David Malcolm wrote: >At Cauldron on the Sunday morning there was a Release Management BoF >session, replacing the specRTL talk (does anyone know what happened to >the latter?) > >One of the topics was bug triage, and how many bug reports lacked basic >metadata on e.g. host/build/target, reproducer etc. > Heh... I was hoping this would be a patch to the driver directly (thus not a python script). Note that I don't care too much about the reproducing/-save-temps and backtrace for the driver option. Of course in case of an ICE producing a proper bug-url with the backtrace info included would even be better. All, we've been trying to upstream a patch for something like this for last month. It doesn't bring you to Bugzilla but at least generates a repro with host/target information and call stack. Could someone take a look? We could certainly enhance it to generate user-friendly links like in David's script. https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01649.html -Y
Re: writing patterns
On Wed, Jul 30, 2014 at 4:49 PM, Richard Biener wrote: > On Wed, Jul 30, 2014 at 1:11 PM, Richard Biener > wrote: >> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >> wrote: >>> Hi, >>>Sorry to ask a stupid question, but I am having issues writing patterns >>> involving casts. I am trying to write patterns from simplify_rotate. >>> >>> Could you show me how to write a patterns that involve >>> casts ? >>> for eg: >>> ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B >>> T -> some unsigned type with bitsize B, and some type T2 wider than T. >>> How to express this in the pattern ? >> >> [copying gcc@ because of the syntax stuff] >> >> for example with (leaving captures as the appear in the pattern above) >> >> (match_and_simplify >>(plus (convert@2 (lshift (convert@0 X) CNT1)) >>(convert (rshift (convert@1 X) CNT2))) >> /* Types T2 have to match */ >>(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) >> /* Type T should be unsigned. */ >>&& TYPE_UNSIGNED (TREE_TYPE (@2)) >>/* T2 should be wider than T. */ >>&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >>/* CNT1 + CNT2 == B */ >>&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >>wi::add (CNT1, CNT2 >>(lrotate CNT1)) > > Note that this will _explicitely_ require a conversion. That is, if T == T2 > it won't match because the conversion to T will not be there, nor if X > is already of type T2. > > Which means that we want to match multiple variants of this > (with conversions in place or not). Hmm. Maybe with extending 'for' like > > (for cvt1 in convert * > (fot cvt2 in convert * > (plus@2 (cvt1 (lshift@0 (cvt2 X) CNT1)) > (cvt1 (rshift@1 (cvt2 X) CNT2))) > ... > > adding an "empty" operator to the list of operators to substitute for cvt1 > and allowing nested for. The "empty" operator would necessarily be > unary and be just un-wrapped. Would it be better to have syntax (say using ?) for denoting that an operator is optional ? operator should be unary, and it's operand must be an expression. so the pattern becomes sth like: (plus@2 (convert? (lshift@0 (convert? X) CNT1)) (convert? (rshift@1 (convert? X) CNT2))) Thanks, Prathamesh > > Extending for in this way avoids treating conversions specially > (I don't see an easy way to do very good at that automagically). We > need multiple patterns in the decision tree here anyway. > > Now guess sth fancy in place of '*' ... > > Lisp style would be less free-form like > > (for cvt (convert ()) > > where we could use an empty list for the "empty" operator. > > Is nested for support already implemented? > > Thanks, > Richard. > >> which suggests that we may want to add some type capturing / matching >> so we can maybe write >> >> (plus (convert@T (lshift (convert@T2 X) CNT1)) >> (convert (rshift (convert@T2 X) CNT2))) >> (if (/* T2s will be matched automagically */ >>&& TYPE_UNSIGNED (@T) >>&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >>&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 >> >> which is less to type and supports requiring matching types. Maybe >> require @T[0-9]+ here thus use @T0 and disallow plain @T. We could >> then also use @T for the implicitely "captured" outermost type we >> refer to as plain 'type' right now. >> >> I suggest to go ahead without a new syntax for now and see if it >> gets unwieldingly ugly without first. >> >>> For this week, I have planned: >>> a) writing patterns from simplify_rotate >>> b) replacing op in c_expr >>> c) writing more test-cases. >>> >>> If there's anything else you would like me to do, I would be happy >>> to know. >> >> Just keep an eye open for things like above - easy ways to reduce >> typing for patterns. >> >> Btw, I suggest to split up match.pd by code you converted from. Thus >> for simplify_rotate add >> >> match-simplify-rotate.pd >> >> with the patterns and do a #include "match-simplify-rotate.pd" >> in match.pd. That will make it easier to match the two later. >> >> Thanks, >> Richard. >> >> >>> Thanks, >>> Prathamesh
Re: GCC version bikeshedding
> What are you objecting to, calling the next release from trunk 5.0, > and the next one after that 6.0? Or the wording chosen to describe the > new versioning scheme? Let's not start another subthread, please, this will be even more confusing. You can reply to my reply to Ian's message if you deem it necessary. -- Eric Botcazou
gcc-4.9-20140730 is now available
Snapshot gcc-4.9-20140730 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140730/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 213313 You'll find: gcc-4.9-20140730.tar.bz2 Complete GCC MD5=6d3877bb4ac88dc9f86320585a47564b SHA1=4ba8fd9657cf6054e3ac0ff0c21371cfb55960b8 Diffs from 4.9-20140723 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
Re: GCC version bikeshedding
On 30 July 2014 23:18, Eric Botcazou wrote: >> What are you objecting to, calling the next release from trunk 5.0, >> and the next one after that 6.0? Or the wording chosen to describe the >> new versioning scheme? > > Let's not start another subthread, please, this will be even more confusing. I'm not. I'm trying to get your message back on topic. > You can reply to my reply to Ian's message if you deem it necessary. Are you objecting to the numbering scheme, or Ian's description of it? If you have an objection to the concrete plan it would be nice if you stated clearly what it is.
Re: Prototype of a --report-bug option
On 07/29/14 12:35, David Malcolm wrote: At Cauldron on the Sunday morning there was a Release Management BoF session, replacing the specRTL talk (does anyone know what happened to the latter?) One of the topics was bug triage, and how many bug reports lacked basic metadata on e.g. host/build/target, reproducer etc. I suggested we could automate gathering this, and rashly promised to write a prototype in Python. So here it is... The attached script demonstrates a way to generate a URL that, when followed, takes the user to the GCC Bugzilla "Enter Bug" page, with all pertinent fields prepopulated with meaningful data. (run the script, and follow the URL; this uses the same server-side URLs as the "Remember values as bookmarkable template" BZ button). The idea is that the "gcc" driver program could gain a --report-bug feature that injects -save-temps into the options, disables plugins, and tries to reproduce a crash. It then gives you the URL to click on, capturing the backtrace and embedding it into the form for you. Perhaps we could guess the "Component" based on the backtrace. I note that there doesn't seem to be a "trunk" entry for "Version". I am both proud of, and scared of, this idea: it could make it easy for people to file higher-quality bugs. On the other hand, that means more bugs in the tracker... (they do at least need to be logged in). Note that this points users at the GCC bug tracker. Presumably downstream packagers of GCC may want to customize such a feature to point at their bug trackers (e.g. at Red Hat we have our own bugzilla instance, with a different set of custom fields). So the obvious question is how does this relate to Jakub's patch that Maxim @ Samsung is trying to get reviewed? Jeff
Re: writing patterns
On Wed, Jul 30, 2014 at 11:49 PM, Prathamesh Kulkarni wrote: > On Wed, Jul 30, 2014 at 4:49 PM, Richard Biener > wrote: >> On Wed, Jul 30, 2014 at 1:11 PM, Richard Biener >> wrote: >>> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >>> wrote: Hi, Sorry to ask a stupid question, but I am having issues writing patterns involving casts. I am trying to write patterns from simplify_rotate. Could you show me how to write a patterns that involve casts ? for eg: ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2)) iff CNT1 + CNT2 == B T -> some unsigned type with bitsize B, and some type T2 wider than T. How to express this in the pattern ? >>> >>> [copying gcc@ because of the syntax stuff] >>> >>> for example with (leaving captures as the appear in the pattern above) >>> >>> (match_and_simplify >>>(plus (convert@2 (lshift (convert@0 X) CNT1)) >>>(convert (rshift (convert@1 X) CNT2))) >>> /* Types T2 have to match */ >>>(if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)) >>> /* Type T should be unsigned. */ >>>&& TYPE_UNSIGNED (TREE_TYPE (@2)) >>>/* T2 should be wider than T. */ >>>&& TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2)) >>>/* CNT1 + CNT2 == B */ >>>&& wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)), >>>wi::add (CNT1, CNT2 >>>(lrotate CNT1)) >> >> Note that this will _explicitely_ require a conversion. That is, if T == T2 >> it won't match because the conversion to T will not be there, nor if X >> is already of type T2. >> >> Which means that we want to match multiple variants of this >> (with conversions in place or not). Hmm. Maybe with extending 'for' like >> >> (for cvt1 in convert * >> (fot cvt2 in convert * >> (plus@2 (cvt1 (lshift@0 (cvt2 X) CNT1)) >> (cvt1 (rshift@1 (cvt2 X) CNT2))) >> ... >> >> adding an "empty" operator to the list of operators to substitute for cvt1 >> and allowing nested for. The "empty" operator would necessarily be >> unary and be just un-wrapped. > Would it be better to have syntax (say using ?) for denoting that an > operator is optional ? > operator should be unary, and it's operand must be an expression. > > so the pattern becomes sth like: > (plus@2 (convert? (lshift@0 (convert? X) CNT1)) > (convert? (rshift@1 (convert? X) CNT2))) > Let me rephrase it. An operator can be marked optional, if a) it's unary b) if in outermost-expr, the operand must be an expression I want to reject case like: (negate? @0) (op? operand) generates code : match (op) match (operand) and once without op match (operand) Implementation-wise I think, we could duplicate the AST, like we do for "for pattern". Would that be okay ? Thanks, Prathamesh > Thanks, > Prathamesh > >> >> Extending for in this way avoids treating conversions specially >> (I don't see an easy way to do very good at that automagically). We >> need multiple patterns in the decision tree here anyway. >> >> Now guess sth fancy in place of '*' ... >> >> Lisp style would be less free-form like >> >> (for cvt (convert ()) >> >> where we could use an empty list for the "empty" operator. >> >> Is nested for support already implemented? >> >> Thanks, >> Richard. >> >>> which suggests that we may want to add some type capturing / matching >>> so we can maybe write >>> >>> (plus (convert@T (lshift (convert@T2 X) CNT1)) >>> (convert (rshift (convert@T2 X) CNT2))) >>> (if (/* T2s will be matched automagically */ >>>&& TYPE_UNSIGNED (@T) >>>&& TYPE_PRECISION (@T2) > TYPE_PRECISION (@T) >>>&& wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2 >>> >>> which is less to type and supports requiring matching types. Maybe >>> require @T[0-9]+ here thus use @T0 and disallow plain @T. We could >>> then also use @T for the implicitely "captured" outermost type we >>> refer to as plain 'type' right now. >>> >>> I suggest to go ahead without a new syntax for now and see if it >>> gets unwieldingly ugly without first. >>> For this week, I have planned: a) writing patterns from simplify_rotate b) replacing op in c_expr c) writing more test-cases. If there's anything else you would like me to do, I would be happy to know. >>> >>> Just keep an eye open for things like above - easy ways to reduce >>> typing for patterns. >>> >>> Btw, I suggest to split up match.pd by code you converted from. Thus >>> for simplify_rotate add >>> >>> match-simplify-rotate.pd >>> >>> with the patterns and do a #include "match-simplify-rotate.pd" >>> in match.pd. That will make it easier to match the two later. >>> >>> Thanks, >>> Richard. >>> >>> Thanks, Prathamesh
