On 27 June 2016 at 14:16, Richard Biener wrote:
> On Sun, Jun 26, 2016 at 5:55 PM, Prasad Ghangal
> wrote:
>> Hi Richard,
>>
>> For the first stage of the project, I have completed the following things -
>> parsed -- assign-statement, labeled-statement, if-statement,
>> switch-statement, goto-sta
On Sun, Jun 26, 2016 at 5:55 PM, Prasad Ghangal
wrote:
> Hi Richard,
>
> For the first stage of the project, I have completed the following things -
> parsed -- assign-statement, labeled-statement, if-statement,
> switch-statement, goto-statement, return-statement;
> handled local declarations and
BB11, i_30, &_BB6);
> ivtmp_59 = __PHI (tmp$10_66, &_BB11, ivtmp_33, &_BB6);
> goto _BB9;
>
>possibly less conflicting would be to allow '11:' as label as
>extension so we can use literal 11 for
>the __PHI argument.
>
>The point of re-using (part
the __PHI argument.
The point of re-using (parts of) the C frontend is that you get types
and decls for free. The GIMPLE
part is really the easy part of writing a gimple FE ;)
You need to shortcut most of the C FEs specialities such as type
promotion rules and stuff, of course.
Richard.
> —
> Yinsong
>
>
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.
/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
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
t;>>> 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 chosen because
>>it
>
> 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
se 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 chosen because it
>> simplifies parsing.
>>
>> You first need to design a text represent
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
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 wa
fies the result. What
I'm struggling with here is balancing the human cost of building a test
in David's kind of framework vs doing something easier in a gimple-FE
like framework vs what we do now where it's bloody hard to arrange for
bits to get to a specific pass in a specific state.
jeff
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
On Sun, Mar 22, 2015 at 02:36:31PM +0800, xue yinsong wrote:
> I add the following code in parser.c to replace htab:
>
> …
> struct gimple_symtab_hasher : ggc_cache_hasher *>
> {
> /* Return the hash value of the declaration name of a
> gimple_symtab_entry_def
> object pointed by ENTRY. */
>
I add the following code in parser.c to replace htab:
…
struct gimple_symtab_hasher : ggc_cache_hasher
{
/* Return the hash value of the declaration name of a gimple_symtab_entry_def
object pointed by ENTRY. */
static hashval_t hash(struct gimple_symtab_entry_def *base){return
IDENTIFIER_H
On Thu, Mar 19, 2015 at 08:36:50PM +0800, xue yinsong wrote:
> Thanks for the guidance.
>
> I tried to merge thunk into this branch.
> However, it seems a small part of Gimple FE is a bit outdated.
>
>
> is_param / is_marked / htab are still used in parser.c
> ( htt
On March 19, 2015 4:57:37 AM GMT+01:00, Trevor Saunders
wrote:
>On Wed, Mar 18, 2015 at 11:09:28PM +0800, xue yinsong wrote:
>>
>>
>>
>>
>>
>> On 15/3/18 下午10:08, "Diego Novillo" wrote:
>>
>> >On Wed, Mar 18, 2015 at 2:54 AM, xue yinsong
> wrote:
>> >
>> >> Somehow this project is not in t
On Wed, Mar 18, 2015 at 11:09:28PM +0800, xue yinsong wrote:
>
>
>
>
>
> On 15/3/18 下午10:08, "Diego Novillo" wrote:
>
> >On Wed, Mar 18, 2015 at 2:54 AM, xue yinsong wrote:
> >
> >> Somehow this project is not in the gsoc ideas list, and it’s been one year
> >> since the last commit(Accord
On Wed, Mar 18, 2015 at 11:09 AM, xue yinsong wrote:
> I’m glad to get started now.
> Could you please give me some specific directions to work on ?
Sorry. I wasn't clear enough. You'd first need to find someone willing
to mentor. I'm not going to be involved in GSoC for GCC this year.
Diego.
On 15/3/18 下午10:08, "Diego Novillo" wrote:
>On Wed, Mar 18, 2015 at 2:54 AM, xue yinsong wrote:
>
>> Somehow this project is not in the gsoc ideas list, and it’s been one year
>> since the last commit(According to
>> https://gcc.gnu.org/svn/gcc/branches/gimple-front-end/ChangeLog).
>>
>>
On Wed, Mar 18, 2015 at 2:54 AM, xue yinsong wrote:
> Somehow this project is not in the gsoc ideas list, and it’s been one year
> since the last commit(According to
> https://gcc.gnu.org/svn/gcc/branches/gimple-front-end/ChangeLog).
>
> Could someone tell me if this project is still active and
33 matches
Mail list logo
