On 15/4/8 下午4:15, "Richard Biener" wrote:
>No. Currently we dump
>
> :
> # i_57 = PHI
> # ivtmp_60 = PHI
> _65 = (int) ratio_mult_vf.8_45;
> tmp.9_64 = i_30 + _65;
> tmp.10_66 = ivtmp_33 - ratio_mult_vf.8_45;
> if (niters.6_41 == ratio_mult_vf.8_45)
>goto ;
> else
>goto ;
>
>
On Wed, Apr 8, 2015 at 4:48 AM, Yinsong Xue wrote:
> On 15/4/7 下午4:33, "Richard Biener" wrote:
>
>>I still like the idea of using C + extensions most. As well as making the
>>-fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting
>>from dump files to generate testcases is currently
On 15/4/7 下午4:33, "Richard Biener" wrote:
>I still like the idea of using C + extensions most. As well as making the
>-fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting
>from dump files to generate testcases is currently somewhat awkward,
>mainly due to the issue how we dump lab
On Tue, Apr 7, 2015 at 3:33 AM, Richard Biener
wrote:
>> Having an IR that is more readable than LLVM's would be nice.
>
> I still like the idea of using C + extensions most.
+1
> As well as making the
> -fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting
> from dump files to gen
On Mon, Apr 6, 2015 at 11:20 PM, Sebastian Pop wrote:
> On Fri, Apr 3, 2015 at 1:10 PM, Jeff Law wrote:
>> On 04/03/2015 09:41 AM, Diego Novillo wrote:
>>>
>>> On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote:
>>> I was hesitant to offer this option, but it's certainly a good
>>> starting point.
On Fri, Apr 3, 2015 at 7:56 PM, Gry Gunvor wrote:
> Gcc melt already advertises that it allows access to the internals:
> http://gcc-melt.org/ ; I have not tried it yet.
>
> This is of course not the same as a format that can be exported and
> then imported again, but it is attempting to get a sim
On Fri, Apr 3, 2015 at 1:10 PM, Jeff Law wrote:
> On 04/03/2015 09:41 AM, Diego Novillo wrote:
>>
>> On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote:
>> I was hesitant to offer this option, but it's certainly a good
>> starting point. The representation encodes CFG, SSA, attributes,
>> declarati
On Fri, Apr 03, 2015 at 09:25:57AM -0600, Jeff Law wrote:
> On 04/03/2015 07:45 AM, Diego Novillo wrote:
> >Not quite. The output of the debug dumpers is not really meant to be fed
> >back to the compiler. They are debug dumps only. They do not contain
> >enough information for code generation or a
On 04/03/2015 09:41 AM, Diego Novillo wrote:
On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote:
I was hesitant to offer this option, but it's certainly a good
starting point. The representation encodes CFG, SSA, attributes,
declarations and annotations. It has a relatively fixed syntax, which
ma
Gcc melt already advertises that it allows access to the internals:
http://gcc-melt.org/ ; I have not tried it yet.
This is of course not the same as a format that can be exported and
then imported again, but it is attempting to get a similar result.
(1) Can anyone comment on the quality/usabilit
On April 3, 2015 5:41:35 PM GMT+02:00, Diego Novillo
wrote:
>On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote:
>> On 04/03/2015 09:30 AM, Diego Novillo wrote:
>>>
>>> On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong
>
>>> wrote:
>>>
So it’s better not to try to read the exact dump format.
C
On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote:
> On 04/03/2015 09:30 AM, Diego Novillo wrote:
>>
>> On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong
>> wrote:
>>
>>> So it’s better not to try to read the exact dump format.
>>> Could we use a similar but more complete syntax instead?
>>
>>
>> Absolu
On 04/03/2015 09:30 AM, Diego Novillo wrote:
On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong wrote:
So it’s better not to try to read the exact dump format.
Could we use a similar but more complete syntax instead?
Absolutely. The initial attempt for gimple fe was to use a tuple-based
syntax tha
On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong wrote:
>So it’s better not to try to read the exact dump format.
>Could we use a similar but more complete syntax instead?
Absolutely. The initial attempt for gimple fe was to use a tuple-based
syntax that is very easy to parse. But that was only chos
On 04/03/2015 07:45 AM, Diego Novillo wrote:
On 04/02/15 11:59, xue yinsong wrote:
I suppose our goal is to translate the dumped program back to
the C source code (otherwise we can simply retain the gotos and
labels since they are already `valid’ in C). In this case we have to
convert the goto
On 15/4/3 下午11:00, "xue yinsong" wrote:
>So it’s better not to try to read the exact dump format.
>Could we use a similar but more complete syntax instead?
>
>——
>Yinsong
>
>On 15/4/3 下午9:45, "Diego Novillo" wrote:
>
>>
>>
>>On 04/02/15 11:59, xue yinsong wrote:
>>> I suppose our goal is t
On 04/02/15 11:59, xue yinsong wrote:
I suppose our goal is to translate the dumped program back to
the C source code (otherwise we can simply retain the gotos and
labels since they are already `valid’ in C). In this case we have to
convert the gotos back to if-elses and whiles. As long as
CFG
On 15/3/30 下午5:40, "Richard Biener" wrote:
>On Mon, Mar 30, 2015 at 11:36 AM, Richard Biener
> wrote:
>> On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong wrote:
>>> Thanks for your reply to my proposal.
>>> AFAIS, most of the files generated by -fdump-tree-all are presented in
>>> C-like form i
On 03/31/2015 09:34 AM, Trevor Saunders wrote:
On Thu, Mar 26, 2015 at 03:15:22PM +0100, Richard Biener wrote:
On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong wrote:
I think the gimple front end project would be quite useful to gcc so I’d like
to do work on it this summer.
The problem is, it se
On Thu, Mar 26, 2015 at 03:15:22PM +0100, Richard Biener wrote:
> On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong wrote:
> > I think the gimple front end project would be quite useful to gcc so I’d
> > like to do work on it this summer.
> >
> > The problem is, it seems the GIMPLE front end project h
On Mon, Mar 30, 2015 at 11:36 AM, Richard Biener
wrote:
> On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong wrote:
>> Thanks for your reply to my proposal.
>> AFAIS, most of the files generated by -fdump-tree-all are presented in
>> C-like form instead
>> of in lisp-like tuple form.
>> So it’s better
On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong wrote:
> Thanks for your reply to my proposal.
> AFAIS, most of the files generated by -fdump-tree-all are presented in C-like
> form instead
> of in lisp-like tuple form.
> So it’s better to implement a front end for the C-like gimple representations.
On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong wrote:
> I think the gimple front end project would be quite useful to gcc so I’d like
> to do work on it this summer.
>
> The problem is, it seems the GIMPLE front end project hasn’t been active for
> some time
> and Diego Novillo told me it may not
23 matches
Mail list logo
