Re: [GSoC] symbol to denote multiple operators
On Thu, Jul 10, 2014 at 8:05 PM, Prathamesh Kulkarni
wrote:
> Hi,
>I have attempted to add syntax for symbol to denote multiple operators.
>
> I tried it with few bogus patterns and it appears to work hopefully -:)
> eg: (bogus pattern):
> (for op in plus minus
> (match_and_simplify
> (op @0 @1)
> (op @0 @0)))
>
> generates following patterns:
> (plus @0 @1) -> (plus @0 @0) // simplify_0
> (plus @0 @1) -> (mult @0 @0) // simplify_1
> (mult @0 @1) -> (plus @0 @0) // simplify_2
> (mult @0 @1) -> (mult @0 @0) // simplify_3
s/mult/minus/? I think it should only generate
(plus @0 @1) -> (plus @0 @0)
(minus @0 @1) -> (minus @0 @0)
to get the what you write we should need to write
(for op1 in plus minus
(for op2 in plus minus
(match_and_simplify
(op1 @0 @1)
(op2 @0 @0
> root (0xab6b10), 0, 2
> |--(PLUS_EXPR) (0xab6b30), 1, 1
> |true (0xab6ba0), 2, 1
> |--true (0xab6c10), 3, 2
> |simplify_0 { 0xab6ba0, 0xab6c10, (nil), (nil), } (0xab6c80), 4, 0
> |simplify_1 { 0xab6ba0, 0xab6c10, (nil), (nil), } (0xab6d40), 4, 0
> |--(MULT_EXPR) (0xab6d00), 1, 1
> |true (0xab6d90), 2, 1
> |--true (0xab6e00), 3, 2
> |simplify_2 { 0xab6d90, 0xab6e00, (nil), (nil), } (0xab6e70), 4, 0
> |simplify_3 { 0xab6d90, 0xab6e00, (nil), (nil), } (0xab6f30), 4, 0
>
> * Changes to rest of the code:
> a) commutating patterns was interfering with this, because
> parse_match_and_simplify, immediately commutated match operand. Symbol
> should be replaced by operators before commutating. This required
> adjusting simplify (back to operand *match), and commutating is done
> in new function lower_commutative. Ideally this should be done during
> insertion in decision tree ?
Yes, commutating should be done by inserting a pattern multiple
times with adjusted AST walk order.
> b) adjustments required to e_operation constructor, so it doesn't
> call fatal, when it does not find id to be in the hash table.
Eventually just temporarily insert a new operator in the hash table
when parsing comes along a (for OP ...? That is, add a new kind,
USER and just re-use base->id?
> * Caveats
> a) new e_operation constructor taking id_base * argument. Not sure
> if that's required.
> b) e_operation::user_id denotes user-defined identifier (),
> a rather apologetic name ...
> c) Similar to commutate(), replace_user_id() does not clone AST's.
> So we have multiple AST's sharing same nodes.
I wonder if we want to parse the 'for' into an AST node instead,
thus not expand it on-the-fly. Applying could then happen during
DT insertion. Or as a separate lowering like you introduce
lower_commutative - that looks cleaner.
Or if we can simply parse the match-and-simplify multiple times, with
the for op replaces, using _cpp_backup_tokens. Ok, no - that
sounds like too much of a hack.
> * add multiple symbols ?
> should we have
> (for in operator-list1, in operator-list2
> (match_and_simplify
> ...))
> or have nested for ?
> (for in operator-list1
>(for in operator-list2
>(match_and_simplify
> )))
It depends on the desired semantics. It's a lot clearer with
single opname for only (but then we eventually need nested for).
> * we don't detect functions with wrong arguments
> for example, we dont give error on:
> (built_in_sqrt @0 @1)
> I guess that's because we don't have an easy way to figure out
> number of arguments a function expects ?
> (is there a built-in equivalent of tree_code_length[] ?)
Yeah, the function stuff is still very simplistic and no, there isn't
any easy way of extracting the number of expected arguments
from builtins.def (it's encoded in the type). The easiest way
would be to change builtins.def to add a number-of-args argument ...
Let's just defer that issue.
As for the patch, we shouldn't do the cartesian_product - that's
hardly ever what the user intends and it means there isn't any
way of repeating the same pattern for multiple operators.
A common use for 'for' would be (for OP in ne eq (...)) as most
equality foldings are valid for ne and eq. Another is
for the various division kinds we have - trunc_div ceil_div floor_div
and round_div (same for mod):
(for op in trunc_div ceil_div floor_div round_div
(match_and_simplify
(op @0 integer_onep)
@0))
(good example for match.pd to exercise the code)
Can you fix the cartesian product thing (it should only simplify the patch)?
Thanks,
Richard.
> * genmatch.c (e_operation::e_operation): New constructor.
> (e_operation::user_id): New member.
> (e_operation::get_op): New member function.
> (simplify::matchers): Remove.
> (simplify::match): New member.
> (lower_commutative): New function.
> (check_operator): Likewise.
> (replace_user_id): Likewise.
> (decision_tree::insert): Adjust to changes in simplify.
> (eat_ident): New function.
> (parse_expr): Call to check_operator.
> (parse_for): New function.
> (main): Add calls to parse_for
Re: mn10300, invariants on DEP_PRO/DEP_CON and on TARGET_SCHED_ADJUST_COST params
On Fri, 2014-07-11 at 10:13 +1200, Maxim Kuvyrkov wrote:
> On Jul 9, 2014, at 8:21 AM, David Malcolm wrote:
>
> > [CCing nickc, who wrote the mn10300 hook in question]
> >
> > I'm experimenting with separating out instructions from expressions in
> > RTL; see [1] for more info on that.
> >
> > I noticed that mn10300 has this implementation of a target hook:
> > #define TARGET_SCHED_ADJUST_COST mn10300_adjust_sched_cost
> >
> > Within mn10300_adjust_sched_cost (where "insn" and "dep" are the first
> > and third parameters respectively), there's this code:
> >
> > if (GET_CODE (insn) == PARALLEL)
> >insn = XVECEXP (insn, 0, 0);
> >
> > if (GET_CODE (dep) == PARALLEL)
> >dep = XVECEXP (dep, 0, 0);
> >
> > However, I believe that these params of this hook ("insn") always
> > satisfy INSN_CHAIN_CODE_P, and so can't have code PARALLEL. [Nick: did
> > those conditionals ever get triggered, or was this defensive coding?]
>
> From what I can tell these are remnants from the early days of
> haifa-sched (10+ years ago). I would be very surprised if scheduler
> didn't ICE on a PARALLEL of INSNs (not to be confused with a PARALLEL
> as INSN_PATTERN).
Thanks. In my experimental patch series [1] I've gone ahead and removed
those checks.
> > Specifically, the hook is called from haifa-sched.c:dep_cost_1 on the
> > DEP_CON and DEP_PRO of a dep_t.
> >
> > It's my belief that DEP_CON and DEP_PRO always satisfy INSN_CHAIN_CODE_P
> > - and on every other config so far that seems to be the case.
> >
> > Is my belief about DEP_CON/DEP_PRO correct? (or, at least, consistent
> > with other gcc developers' views on the matter :)) My patch kit [2] has
> > this expressed in the type system as of [3], so if I'm incorrect about
> > this I'd prefer to know ASAP.
>
> Yes, it is correct.
Thanks; that's reassuring.
> >
> > Similarly, do the first and third params of TARGET_SCHED_ADJUST_COST
> > also satisfy INSN_CHAIN_CODE_P?
> >
>
> Yes, since they are always derived from DEP_CON / DEP_PRO.
(nods)
Thanks again
Dave
[1] fwiw, latest work-in-progress of instructions vs expressions:
http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v12/
with the removal of the redundant checks for PARALLEL in:
http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v12/0205-FIXME-config-mn10300-Fix-for-target.def-patch.patch
Re: GCC 4.9.1 Status Report (2014-07-10)
Hi All, Thank you for your suggestions. Unfortunately, no way! I tried these actions: 1. using apple-gcc4.2 for building my cross gcc compiler 2. I tried XCode (llvm) 3. I tried to add this make CFLAGS="-g -O2 -fbracket-depth=512” (512, 1024, 2048 … no way)! 4. I can generate my cross compiler based on the "gcc 4.8.3” without problem (using both the apple-gcc4.2 or the XCode llvm) So, what has changed of fundamental between the 4.8.3 and the 4.9 versions? So, I am a bit without ideas Cheers, Edo On 11 Jul 2014, at 00:29, Joel Sherrill wrote: > > On 7/10/2014 5:14 PM, pins...@gmail.com wrote: >> >>> On Jul 10, 2014, at 3:13 PM, Ian Lance Taylor wrote: >>> On Thu, Jul 10, 2014 at 11:40 AM, Franzi Edo. wrote: As for the version 4.9.0, on OSX stil remain a problem. I cannot build an ARM a cross compiler! Here is the message (same as for the 4.9.0) ... .../Packages/gcc-4.9.1/gcc/config/arm/neon.md:3486:10917: fatal error: bracket nesting level exceeded maximum of 256 .../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 >>> You did not include enough context to be sure, but I don't think that >>> error message is coming from GCC. At least, I don't see that error >>> message in the GCC sources. >>> >>> I think that error message is coming from the host compiler you are >>> using, in which case, based on the error message, the solution would >>> seem to be >>> make CFLAGS="-g -O2 -fbracket-depth=512" >> Also i thought we did not support cross building with anything besides gcc. > The RTEMS community sees this when using clang/llvm on FreeBSD. > > Franzi.. did the suggestion from Chris Johns to increase the limit > to 1024, not work? > > https://gcc.gnu.org/ml/gcc/2014-05/msg00018.html > > This ended up being reported at http://llvm.org/bugs/show_bug.cgi?id=19650 > > --joel >> Thanks, >> Andrew >> >>> Ian > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 >
Linux Plumbers Development Tools Microconference
Hello, I am organizing a Development Tools microconference at the 2014 Linux Plumbers conference: http://www.linuxplumbersconf.org/2014/ http://wiki.linuxplumbersconf.org/2014:development_tools_coccinelle_sparse_etc The goal is both to share information about tools that may be relevant to Linux developers and to share information about what kinds of tools Linux devlopers may find relevant. If you would be interested in participating, with or without giving a presentation, please let me know. thanks, Julia Lawall
Re: GCC 4.9.1 Status Report (2014-07-10)
On 12/07/2014 4:52 am, Franzi Edo. wrote: make CFLAGS="-g -O2 -fbracket-depth=512” (512, 1024, 2048 … no way)! For a cross-compiler I think this should be BUILD_CFLAGS and I suggest 1024 rather than 512 ? Chris
