Re: LTO and version scripts
On Wed, Aug 6, 2014 at 11:07 PM, Alan Modra wrote: > Both Fedora 19 and 20 have the patch needed for this to work. Hmm, I > suppose the other thing necessary is a gcc that implements > LDPT_GET_SYMBOLS_V2. You may be lacking that. Here's what I see with > mainline gcc and ld. It's been a while since I tried it and this was a larger project. I can confirm that with the current binutils on Fedora 19 it does work as expected. I'll keep an eye out for this.
Re: [GSoC] replacing op in c_expr
On Mon, Aug 4, 2014 at 2:13 PM, Richard Biener
wrote:
> On Sun, Aug 3, 2014 at 6:58 PM, Prathamesh Kulkarni
> wrote:
>> On Tue, Jul 29, 2014 at 4:29 PM, Richard Biener
>> wrote:
>>> On Mon, Jul 28, 2014 at 10:02 PM, Prathamesh Kulkarni
>>> wrote:
I am having few issues replacing op in c_expr.
I thought of following possibilities:
a) create a new vec vector new_code.
for each token in code
{
if token.type is not CPP_NAME
new_code.safe_push (token);
else
{
cpp_token new_token =
??? create new token of type CPP_NAME
with contents as name of operator ???
}
}
I tried to go this way, but am stuck with creating a new token type.
i started by:
cpp_token new_token = token; // get same attrs as token.
CPP_HASHNODE (new_token.val.node.node)->ident.str = name of operator.
CPP_HASHNODE (new_token.val.node.node)->ident.len = len of operator name.
name of operator is obtained from opers[i] in parse_for.
however this does not work because I guess
new_token = token, shallow copies
the token (default assignment operator, i didn't find an overloaded
version).
b) create new struct c_expr_elem and use
vec code, instead of vec code;
sth like:
struct c_expr_elem
{
enum c_expr_elem_type { ID, TOKEN };
enum c_expr_elem_type type;
union {
cpp_token token;
const char *id;
};
};
while replacing op, compare token with op, and if it matches,
create a new c_expr_elem with type = ID, and id = name of operator.
This shall probably work, but shall require many changes to other parts
since we change c_expr::code.
I would like to hear any other suggestions.
>>>
>>> Together with the vector of tokens recorded at parse_c_expr time
>>> record a vector of token mappings (op -> plus, op2 -> ...) and do
>>> the replacement at code-generation time where we also special-case
>>> captures.
>>>
>>> Yeah, it's a but unfortunate that c_expr parsing is done the way it
>>> is done
>> Thanks. I guess we would require a multi-map for this since there can
>> be many operators
>> (op -> [plus, minus], op2 -> [negate]) ?
>
> Well, it would be enough to attach the mapping to c_expr()s after the
> AST lowering when there is at most one? Because obviously
> code-generation cannot know which to replace.
>
>> Unfortunately, I somehow seem to have missed your response and ended up with
>> a
>> hackish way of doing it, although it works. I will soon change that to
>> use token mappings.
>>
>> I mostly followed b), except i made it sub-class of cpp_token, so the
>> other code using c_expr::code
>> (outline_c_expr, c_expr::gen_transform) did not require changes except
>> for special-casing op.
>
> Indeed not too ugly. Still at the point where you replace in the for()
> processing
>
> - operand *result_op = replace_id (s->result, user_id, opers[i]);
> +
> + operand *result_op;
> + if (is_a (s->result))
> + result_op = replace_op_in_c_expr (s->result, user_id,
> opers[i]);
> + else
> + result_op = replace_id (s->result, user_id, opers[i]);
> +
> +
>
> it should be "easy" to attach a replacemet vector/map to the c_expr
> and use that duing code-generation.
>
> Note that sub-expressions can also be c_exprs, thus
>
> (match-and-simplify
>()
>(plus { ... } @2))
>
> I don't think your patch covers that. That is, you should add
> c_expr handing to replace_id instead.
Thanks, this patch covers that case.
For now, I have still kept the old way, since the change was one-liner.
I will change it after I am done with conditional convert
* genmatch.c (c_expr::elem): New struct.
(c_expr::code): Change type to vec.
(replace_op_in_c_expr): New function.
(replace_id): Call replace_op_in_c_expr.
(c_expr::gen_transform): Adjust to changes in c_expr.
(outline_c_expr): Likewise.
(parse_c_expr): Likewise.
(parse_for): Call replace_op_in_c_expr.
Thanks,
Prathamesh
>
> Richard.
>
>> * genmatch.c (c_expr::elem): New struct.
>> (c_expr::code): Change type to vec.
>> (replace_op_in_c_expr): New function.
>> (c_expr::gen_transform): Adjust to changes in c_expr.
>> (outline_c_expr): Likewise.
>> (parse_c_expr): Likewise.
>> (parse_for): Call replace_op_in_c_expr.
>>
>> Thanks,
>> Prathamesh
>>
>>>
>>> Richard.
>>>
Thanks,
Prathamesh.
Index: genmatch.c
===
--- genmatch.c (revision 213756)
+++ genmatch.c (working copy)
@@ -239,11 +239,20 @@ struct expr : public operand
struct c_expr : public operand
{
- c_expr (cpp_reader *r_, vec code_, unsigned nr_stmts_)
+ struct elem: public cpp_token
+{
+ enum elem_type { TOKEN, ID
Re: writing patterns
On Tue, Aug 5, 2014 at 3:15 PM, Richard Biener wrote: > On Mon, Aug 4, 2014 at 4:44 PM, Prathamesh Kulkarni > wrote: >> On Mon, Aug 4, 2014 at 2:59 PM, Richard Biener >> wrote: >>> On Mon, Aug 4, 2014 at 12:16 AM, Prathamesh Kulkarni >>> wrote: On Thu, Jul 31, 2014 at 2:49 PM, Prathamesh Kulkarni wrote: > On Thu, Jul 31, 2014 at 2:44 PM, Richard Biener > wrote: >> On Thu, Jul 31, 2014 at 11:09 AM, Prathamesh Kulkarni >> wrote: >>> On Thu, Jul 31, 2014 at 2:15 PM, Richard Biener >>> wrote: On Thu, Jul 31, 2014 at 7:41 AM, Prathamesh Kulkarni wrote: > 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 ? I thought of something similar but how exactly would you do the duplication in the above example? The point is that we know that the conversions will exist in pairs, that is, either the two outer and no inner or no outer and both inner or both outer and both inner. You can express that with the nested for - with just a '?' you can't do that. Of course you could do sth like (plus@2 (convert?1 (lshift@0 (convert?2 X) CNT1)) (convert?1 (rshift@1 (convert?2 X) CNT2))) that is, add an index to ?s and tie them together. We want to avoid gener
[GSoC] CSE result-ops
Should we CSE result-op (if result-op is not c_expr) ? for example: match-op1 -> result-op1 match-op2 -> result-op1 we generate code as: match-op1 result-op1 match-op2 result-op1 instead generate: match-op1 goto l1; match-op2 goto l1; l1: result-op1 In general, for patterns. match-op1 -> result-op1, match-op2 -> result-op2 .. generate code as: match-op1 goto l1 match-op2 goto l2 l1: result-op1 l2: result-op2 We would need to compare AST's for this. Not sure how to do it for c_expr. Maybe lexicographically compare tokens by comparing c_expr::code of both c_expr's ? Thanks, Prathamesh
gcc-4.10-20140810 is now available
Snapshot gcc-4.10-20140810 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.10-20140810/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.10 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 213794 You'll find: gcc-4.10-20140810.tar.bz2Complete GCC MD5=a21743b0eaf4271c65b3dfc818c43b24 SHA1=6e5a298a25cdf77ad3171a31613b92249ca4c3eb Diffs from 4.10-20140803 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.10 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: writing patterns
On Mon, Aug 11, 2014 at 2:53 AM, Prathamesh Kulkarni wrote: > On Tue, Aug 5, 2014 at 3:15 PM, Richard Biener > wrote: >> On Mon, Aug 4, 2014 at 4:44 PM, Prathamesh Kulkarni >> wrote: >>> On Mon, Aug 4, 2014 at 2:59 PM, Richard Biener >>> wrote: On Mon, Aug 4, 2014 at 12:16 AM, Prathamesh Kulkarni wrote: > On Thu, Jul 31, 2014 at 2:49 PM, Prathamesh Kulkarni > wrote: >> On Thu, Jul 31, 2014 at 2:44 PM, Richard Biener >> wrote: >>> On Thu, Jul 31, 2014 at 11:09 AM, Prathamesh Kulkarni >>> wrote: On Thu, Jul 31, 2014 at 2:15 PM, Richard Biener wrote: > On Thu, Jul 31, 2014 at 7:41 AM, Prathamesh Kulkarni > wrote: >> 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 ? > > I thought of something similar but how exactly would you do the > duplication in the above example? The point is that we know > that the conversions will exist in pairs, that is, either > the two outer and no inner or no outer and both inner or > both outer and both inner. You can express that with the > nested for - with just a '?' you can't do that. Of course you could > do sth like > > (plus@2 (convert?1 (lshift@0 (conve
