Utilizing gperf for TableGen

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Utilizing gperf for TableGen

Wilhansen Li-2
The output of TableGen (intrinsics.gen) seems a bit too clunky
specifically the switching parts (input the string, output the enum).
Moreover, the code makes MSVC barf due to its nesting limit which even
applices to if-else statements.

One one hand, gperf
(http://www.gnu.org/software/gperf/manual/gperf.html) offers a way to
map strings to records without much difficulty (and it does its job
efficiently).

My point is, are there plans to utilize gperf for table generation?
--
(<_<)(>_>)(>_<)(<.<)(>.>)(>.<)
Life is too short for dial-up.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Ralph Corderoy

Hi Wilhansen,

> The output of TableGen (intrinsics.gen) seems a bit too clunky
> specifically the switching parts (input the string, output the enum).
> Moreover, the code makes MSVC barf due to its nesting limit which even
> applices to if-else statements.

Does introducing gotos into the generated code help as a temporary
workaround for MSVC?

Cheers,


Ralph.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Anton Korobeynikov
In reply to this post by Wilhansen Li-2
Hello,

> One one hand, gperf
> (http://www.gnu.org/software/gperf/manual/gperf.html) offers a way to
> map strings to records without much difficulty (and it does its job
> efficiently).
>
> My point is, are there plans to utilize gperf for table generation?
I'm aware about gperf. However we're planning to utilize some another
approach based on tries. The idea behind this is pretty simple: almost
all strings being mapped have the form: "foo.bar.baz", so the idea is to
split stuff more or less effectively on such blocks and switch over them.

The advantages are: make stuff in TableGen better, bring up new data
structure to LLVM :).

Gperf will be also fine and almost automatic solution, but this is extra
dependence (and, even worse, some extra headache with maintaining of
auto-generated files), which LLVM tries to reduce.

--
WBR, Anton Korobeynikov
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Christopher Lamb
In reply to this post by Wilhansen Li-2
I believe that some of this will be alleviated by switching to a Trie data structure, though Anton would know for sure.

--
Christopher Lamb

On Jan 1, 2008, at 3:51 AM, Wilhansen Li wrote:

The output of TableGen (intrinsics.gen) seems a bit too clunky
specifically the switching parts (input the string, output the enum).
Moreover, the code makes MSVC barf due to its nesting limit which even
applices to if-else statements.

One one hand, gperf
map strings to records without much difficulty (and it does its job
efficiently).

My point is, are there plans to utilize gperf for table generation?
-- 
(<_<)(>_>)(>_<)(<.<)(>.>)(>.<)
Life is too short for dial-up.
_______________________________________________
LLVM Developers mailing list





_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Chris Lattner
In reply to this post by Wilhansen Li-2

On Jan 1, 2008, at 1:51 AM, Wilhansen Li wrote:

> The output of TableGen (intrinsics.gen) seems a bit too clunky
> specifically the switching parts (input the string, output the enum).
> Moreover, the code makes MSVC barf due to its nesting limit which even
> applices to if-else statements.

Right, fixing the VC++ issue is straight-forward.  I will do it in the  
next couple of days if noone beats me to it.


> One one hand, gperf
> (http://www.gnu.org/software/gperf/manual/gperf.html) offers a way to
> map strings to records without much difficulty (and it does its job
> efficiently).
>
> My point is, are there plans to utilize gperf for table generation?

Not that I know of.  Anton is working on a better and more aggressive  
implementation of this code in question though,

-Chris

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Evan Cheng-2
In reply to this post by Wilhansen Li-2

On Jan 1, 2008, at 1:51 AM, Wilhansen Li wrote:

> The output of TableGen (intrinsics.gen) seems a bit too clunky
> specifically the switching parts (input the string, output the enum).
> Moreover, the code makes MSVC barf due to its nesting limit which even
> applices to if-else statements.
>
> One one hand, gperf
> (http://www.gnu.org/software/gperf/manual/gperf.html) offers a way to
> map strings to records without much difficulty (and it does its job
> efficiently).
>
> My point is, are there plans to utilize gperf for table generation?

There isn't any plan to do so. I agree the output of TableGen can be  
much improved. But this hasn't been a high priority issue. If you have  
an interest in improving this, please do! But I would prefer the  
improvement be made in TableGen that would not require another  
external tool.

Thanks!

Evan

>
> --
> (<_<)(>_>)(>_<)(<.<)(>.>)(>.<)
> Life is too short for dial-up.
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Chris Lattner
In reply to this post by Wilhansen Li-2
On Tue, 1 Jan 2008, Wilhansen Li wrote:
> The output of TableGen (intrinsics.gen) seems a bit too clunky
> specifically the switching parts (input the string, output the enum).
> Moreover, the code makes MSVC barf due to its nesting limit which even
> applices to if-else statements.

This should be fixed now, please verify, thanks!

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Reid Spencer-2
In reply to this post by Chris Lattner
FYI, gperf is a very good perfect hash utility written originally by Doug Schmidt (of ACE fame). I used it in XPS for speeding up XML parsing by hashing all the element and attribute names.  Unfortunately, its a code generator, which we're trying to get rid of in LLVM. Still, I recommend the tool highly.

Reid.

On Tue, 1 Jan 2008 13:04:57 -0800
 Chris Lattner <[hidden email]> wrote:

>
>On Jan 1, 2008, at 1:51 AM, Wilhansen Li wrote:
>
>> The output of TableGen (intrinsics.gen) seems a bit too clunky
>> specifically the switching parts (input the string, output the enum).
>> Moreover, the code makes MSVC barf due to its nesting limit which even
>> applices to if-else statements.
>
>Right, fixing the VC++ issue is straight-forward.  I will do it in the  
>next couple of days if noone beats me to it.
>
>
>> One one hand, gperf
>> (http://www.gnu.org/software/gperf/manual/gperf.html) offers a way to
>> map strings to records without much difficulty (and it does its job
>> efficiently).
>>
>> My point is, are there plans to utilize gperf for table generation?
>
>Not that I know of.  Anton is working on a better and more aggressive  
>implementation of this code in question though,
>
>-Chris
>
>_______________________________________________
>LLVM Developers mailing list
>[hidden email]         http://llvm.cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Wilhansen Li
In reply to this post by Wilhansen Li-2
On Wed, 2 Jan 2008, Chris Lattner wrote:
>This should be fixed now, please verify, thanks!
>
>-Chris

The newer code that TableGen produces is indeed lower however, MSVC
still throws the same error messages (and moreover, I don't think
they're fixing it anytime soon.. I'll try to re-open this issue to
them). Also, it seems that the new code produces an extraneous "if
(0);" statement before each of the else-if chains. Normally, compilers
would (and should) just optimize them away but it still counts agains
MSVC's ``nesting limit''.
--
(<_<)(>_>)(>_<)(<.<)(>.>)(>.<)
Life is too short for dial-up.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Wilhansen Li
In reply to this post by Chris Lattner
The newer code that TableGen produces is indeed lower however, MSVC
still throws the same error messages (and moreover, I don't think
they're fixing it anytime soon.. I'll try to re-open this issue to
them). Also, it seems that the new code produces an extraneous "if
(0);" statement before each of the else-if chains. Normally, compilers
would (and should) just optimize them away but it still counts agains
MSVC's ``nesting limit''.

On 1/3/08, Chris Lattner <[hidden email]> wrote:

> On Tue, 1 Jan 2008, Wilhansen Li wrote:
> > The output of TableGen (intrinsics.gen) seems a bit too clunky
> > specifically the switching parts (input the string, output the enum).
> > Moreover, the code makes MSVC barf due to its nesting limit which even
> > applices to if-else statements.
>
> This should be fixed now, please verify, thanks!
>
> -Chris
>
> --
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


--
(<_<)(>_>)(>_<)(<.<)(>.>)(>.<)
Life is too short for dial-up.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Wilhansen Li-2
In reply to this post by Reid Spencer-2
I'm a bit familiar with the algorithm behind gperf (though I still
have to actually study the source code since they added something
after publishing the paper about gperf). So, is it possible to
reimplement that algorithm in the TableGen of LLVM? That would
eliminate the dependency to gperf however, since gperf is GPLv2'ed,
will the licenses be compatible? AFAIK, yes.

OT: Sorry for my multiple sends to the mailing list, been wrestling
with GMail having two mail accounts.

On 1/3/08, Reid Spencer <[hidden email]> wrote:

> FYI, gperf is a very good perfect hash utility written originally by Doug Schmidt (of ACE fame). I used it in XPS for speeding up XML parsing by hashing all the element and attribute names.  Unfortunately, its a code generator, which we're trying to get rid of in LLVM. Still, I recommend the tool highly.
>
> Reid.
>
> On Tue, 1 Jan 2008 13:04:57 -0800
>  Chris Lattner <[hidden email]> wrote:
> >
> >On Jan 1, 2008, at 1:51 AM, Wilhansen Li wrote:
> >
> >> The output of TableGen (intrinsics.gen) seems a bit too clunky
> >> specifically the switching parts (input the string, output the enum).
> >> Moreover, the code makes MSVC barf due to its nesting limit which even
> >> applices to if-else statements.
> >
> >Right, fixing the VC++ issue is straight-forward.  I will do it in the
> >next couple of days if noone beats me to it.
> >
> >
> >> One one hand, gperf
> >> (http://www.gnu.org/software/gperf/manual/gperf.html) offers a way to
> >> map strings to records without much difficulty (and it does its job
> >> efficiently).
> >>
> >> My point is, are there plans to utilize gperf for table generation?
> >
> >Not that I know of.  Anton is working on a better and more aggressive
> >implementation of this code in question though,
> >
> >-Chris
> >
> >_______________________________________________
> >LLVM Developers mailing list
> >[hidden email]         http://llvm.cs.uiuc.edu
> >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


--
(<_<)(>_>)(>_<)(<.<)(>.>)(>.<)
Life is too short for dial-up.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Chris Lattner
In reply to this post by Wilhansen Li

On Jan 3, 2008, at 6:57 AM, Wilhansen Li wrote:

> On Wed, 2 Jan 2008, Chris Lattner wrote:
>> This should be fixed now, please verify, thanks!
>>
>> -Chris
>
> The newer code that TableGen produces is indeed lower however, MSVC
> still throws the same error messages (and moreover, I don't think
> they're fixing it anytime soon.. I'll try to re-open this issue to
> them). Also, it seems that the new code produces an extraneous "if
> (0);" statement before each of the else-if chains. Normally, compilers
> would (and should) just optimize them away but it still counts agains
> MSVC's ``nesting limit''.

Alright, try this:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071231/056771.html

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Utilizing gperf for TableGen

Bill Wendling
In reply to this post by Wilhansen Li
On Jan 3, 2008, at 6:57 AM, Wilhansen Li wrote:

> On Wed, 2 Jan 2008, Chris Lattner wrote:
>> This should be fixed now, please verify, thanks!
>>
>> -Chris
>
> The newer code that TableGen produces is indeed lower however, MSVC
> still throws the same error messages (and moreover, I don't think
> they're fixing it anytime soon.. I'll try to re-open this issue to
> them). Also, it seems that the new code produces an extraneous "if
> (0);" statement before each of the else-if chains. Normally, compilers
> would (and should) just optimize them away but it still counts agains
> MSVC's ``nesting limit''.

I think the "if (0);" is there to make the code generator easier. The  
loop that produces the if-then statements now just has to generate  
the text:

        else if (...)
          IntrinsicID = ...;

instead of checking if it should emit the "else".

-bw
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Fwd: Utilizing gperf for TableGen

Wilhansen Li-2
In reply to this post by Chris Lattner
---------- Forwarded message ----------
From: Wilhansen Li <[hidden email]>
Date: Jan 4, 2008 6:18 PM
Subject: Re: [LLVMdev] Utilizing gperf for TableGen
To: Chris Lattner <[hidden email]>


It finally compiles well with MSVC. Thanks!

On 1/4/08, Chris Lattner <[hidden email]> wrote:
>
>
> Alright, try this:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20071231/056771.html
>
> -Chris
>


--
(<_<)(>_>)(>_<)(<.<)(>.>)(>.<)
Life is too short for dial-up.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev