search for: krxhuezf

...with -O1 made llvm extremely slow. Another thing that makes llvm incredibly slow is loading/storing large aggregates directly (I know, now, that you're not supposed to do that). I guess it's the generation of the resulting spilling code that takes forever. See e.g. http://pastebin.com/krXhuEzF All that said: we will also keep our original code generators in our compiler, and keep llvm as an option to optimise extra. In terms of speed, our code generators are much less complex and hence much faster than llvm's. We don't have instruction selection, but directly generate assemb...

...s should be handled reasonably efficiently (or, in other words, that other sizes should result in a compile time error). I hadn't seen the "Performance tips for frontend authors" before, and indeed got very ugly code when trying to load/store a [256 x i16] (http://pastebin.com/krXhuEzF ). I had expected LLVM to generate at least a simple copy loop. I can of course also generate it in our frontend (after which llvm can then try to unroll and/or vectorise it :), but it feels redundant. Jonas

Hello, Recently Jonathan Blow posted a short screencast discussing build time of his compiler with when no optimizations are run on the user's code. Part 1: https://www.youtube.com/watch?v=HLk4eiGUic8 Part 2: https://www.youtube.com/watch?v=mIjGYbol0O4 He discusses what parts are taking the longest to compile, and the ultimately shows this: http://i.imgur.com/BkbKcJK.png ...which shows that

2015-08-17 11:26 GMT-07:00 Mehdi Amini <mehdi.amini at apple.com>: > Hi, > > On Aug 17, 2015, at 12:13 AM, deadal nix via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 2015-08-16 23:21 GMT-07:00 David Majnemer <david.majnemer at gmail.com>: > >> >> >> Because a solution which doesn't generalize is not a very powerful