similar to: [LLVMdev] Utilizing gperf for TableGen

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

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/

---------- Forwarded message ---------- From: Wilhansen Li <krad at crammerz-inc.net> Date: Jan 4, 2008 6:18 PM Subject: Re: [LLVMdev] Utilizing gperf for TableGen To: Chris Lattner <sabre at nondot.org> It finally compiles well with MSVC. Thanks! On 1/4/08, Chris Lattner <sabre at nondot.org> wrote: > > > Alright, try this: >

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

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 <sabre at nondot.org>

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

https://gist.github.com/oneman/5394332 This is a little hack for sending -live encoded- WebM streams to Icecast from STDIN. An example (I was using libav from git, params likely different between libav, ffmpeg etc programs) avconv -v debug -f video4linux2 -s 320x240 -r 10 -i /dev/video0 -vcodec libvpx -threads 2 -vb 128k -r 10 -f webm pipe:1 | krad_pipe2 europa.kradradio.com 8008

Howdy, I've been working on WebM support for Icecast, and I'm looking for a few power-users or developers that can work with me on a semi-informal basis to fully test things out, determine what is wanted where and all of those good things. I've been working on things in a cave so to speak, but I am opening things up as much and as fast as I can now. It would be most useful if whomever

Howdy, I've been working on WebM support for Icecast, and I'm looking for a few power-users or developers that can work with me on a semi-informal basis to fully test things out, determine what is wanted where and all of those good things. I've been working on things in a cave so to speak, but I am opening things up as much and as fast as I can now. It would be most useful if whomever

For those who want to test webm streaming. This is a super early test binary release, not super user friendly yet. Here is a link to the server with some streams: http://deimos.kradradio.com:8080/ To play with mplayer: mplayer -cache 2200 http://deimos.kradradio.com:8080/teststream18.webm To play in browser http://deimos.kradradio.com:8080/teststream18.webm To get the app and some

For those who want to test webm streaming. This is a super early test binary release, not super user friendly yet. Here is a link to the server with some streams: http://deimos.kradradio.com:8080/ To play with mplayer: mplayer -cache 2200 http://deimos.kradradio.com:8080/teststream18.webm To play in browser http://deimos.kradradio.com:8080/teststream18.webm To get the app and some

TLDR: Figuring out whether a declaration is a TLI LibFunc is slow.  We hammer that path in CGP.  I'm proposing storing the ID of a TLI LibFunc in the same IntID field in Function we use for IntrinsicID to make that fast. Looking into a compile time issue during codegen (LLC) for a large IR file, I came across something interesting.  Due to the presence of a very large number of intrinsics in

Hi Chris, Function is currently 108 bytes large. Could 4 more bytes really be an issue? Actually 2 should suffice. While I understand that some applications value storage more than anything, many applications value compilation time very highly. getIntrinsicID is called all over the place (isIntrinsic uses it as well), and every single time it checks the function name. To me that sounds a lot

On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com> wrote: >>> It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry. >> >> I tried doing that a few years ago. It’s not nearly as easy as it sounds because we’ve got hardcoded references to various target intrinsics scattered

Hi Jeffrey, Please correct me if I'm wrong, but I believe a test that checks for the old behavior would be pointless. I realize that my patch would return an unmatching intrinsicID when the function's name changes, but the real question we should ask is do we really want to be able to change the intrinsicID by changing the function's name? Also, the original Function constructor

All, I've made a new release of libshout. Greg Maxwell contributed support for the Opus audio codec (opus-codec.org). Tested with gstreamer and oggfwd as source clients, and playback with Firefox Nightly and 'curl | opusdec'. Thanks, Greg. There are no other updates; in particular webm streaming still requires the caller limit the send rate. The source package is available: -

On Oct 16, 2009, at 5:50 AM, Nicolas Capens wrote: > Hi all, > > While profiling I discovered that the Function::getIntrinsicID() > method is called a lot, and every time it uses string comparison to > recompute the ID number. As far as I know the name of an intrinsic > function doesn’t change, so the ID could be determined just once at > Function construction time.

It is possible to change the name of a Function with Value::setName, so this patch _could_ cause incorrect answers. You should add a test that calls setName("intrinsic.name") to make sure this keeps working, regardless of where this patch goes. You might be able to catch such events in the ValueSymbolTable and update the intrinsic ID, but I can't find an obvious place to put that

Hi all, While profiling I discovered that the Function::getIntrinsicID() method is called a lot, and every time it uses string comparison to recompute the ID number. As far as I know the name of an intrinsic function doesn't change, so the ID could be determined just once at Function construction time. I've attached a patch that does this and it appears to work for the code I

Any takers? This patch improves on the previous one by making getIntrinsicID() inline. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091017/9406e0ad/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: FastIntrinsicID-2.patch Type: