This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly Elemental functions) for C



> -----Original Message-----
> From: Jakub Jelinek [mailto:jakub@redhat.com]
> Sent: Tuesday, November 19, 2013 11:31 AM
> To: Joseph S. Myers
> Cc: Iyer, Balaji V; gcc-patches@gcc.gnu.org; Aldy Hernandez
> (aldyh@redhat.com); Jeff Law
> Subject: Re: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly Elemental
> functions) for C
> 
> On Tue, Nov 19, 2013 at 04:13:34PM +0000, Joseph S. Myers wrote:
> > On Tue, 19 Nov 2013, Jakub Jelinek wrote:
> >
> > > Also, I wonder if you couldn't save the tokens wrapped into some
> > > tree temporarily into the attribute, rather than having to adjust
> > > c_parser_attribute callers.  Joseph, what do you prefer here?
> >
> > I think including whatever parsed data is relevant to this attribute
> > in the structure returned by c_parser_attributes (which is currently a
> > tree)
> 
> Well, it has to have an array of tokens, because it can't be parsed until the
> arguments of the function (which may come afterwards) are parsed.
> But IMHO it can be just created as vec<..., va_gc> of the tokens and pointer
> to that added to some magic tree code, or could be kept in an on-the-size
> data structure (say, put in an INTEGER_CST index into some vector inside of
> c_parser into the vector attribute argument temporarily, push the tokens
> into that vector and release it from the vector after parsing the function
> parameters (where OpenMP #pragma omp declare simd is parsed right
> now).
> That parsing then transforms it into a normal tree arguments.
> 

I just need a clarification, so I am sorry if I am making you repeat:

Right now, the array of tokens (vec<c_token> elem_fn_tokens) is passed in as a parameter and then passed back to the c_parser_declaration_or_fndef function.

Instead of that, you would like this information to be stored in parser->specs (using the c_parser_declspecs function) and then have my own routine that will go through these tokens and store them in the DECL_ATTRIBUTES (very similar to what c_finish_omp_declare_simd does).

Am I correct? Did I mistake anything?

Thanks,

Balaji V. Iyer.

> 	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]