similar to: [LLVMdev] [RFC] Stripping unusable intrinsics

Ok… I bit. Alex’s proposal here is really compelling to me because it means that the required changes to make this work would be more limited. Specifically a clang attribute could give us all the benefits of #ifdefs throughout the code without the maintenance burden. So, being the silly person I am, I wrote the patches for clang. I’ve never done any frontend hacking before, so take these with

> On Dec 19, 2014, at 12:34 AM, Alex Rosenberg <alexr at leftfield.org> wrote: > > Putting aside the several minor bikesheds we will get to if we go this route, how close does this approach get to the code shrink you were originally trying to achieve? I haven't yet adjusted my tablegen changes to take advantage of the, but it is on my list for today. > > Are there any

> On Dec 10, 2014, at 4:22 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Wed Dec 10 2014 at 3:57:25 PM Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > llvm-dev, > > In my ongoing saga to improve LLVM for embedded use, we would like to support stripping out unused intrinsics based on the LLVM targets actually

I’ve got some new patches and some numbers. The patches are all the changes required to strip intrinsics using the preprocessor defines I showed in my earlier patches. It actually isn’t that much change to LLVM. Clang will need similar changes too. There were only 9 files that referenced target intrinsics outside the corresponding target. These patches are still WIP, and there is some nastiness,

On Mon, Dec 22, 2014 at 12:55 PM, Chris Bieneman <beanz at apple.com> wrote: > > On Dec 22, 2014, at 12:02 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > On Fri, Dec 19, 2014 at 3:39 PM, Chris Bieneman <beanz at apple.com> wrote: > >> More diffs to enjoy. >> >> I’ve updated my tablegen patches to work with the

On Fri, Dec 19, 2014 at 3:39 PM, Chris Bieneman <beanz at apple.com> wrote: > More diffs to enjoy. > > I’ve updated my tablegen patches to work with the clang::impossible_enum > attribute. With these changes I am seeing the same code size regressions > that #ifdefs were showing — without all the ifdefs. > > That’s about a 2% decrease in our library for WebKit. > >

Circling back to Chandler on file size differences. Here are the highlights of what is different. For my analysis I built LLVM and Clang using a clang built with my patches. The same clang was used for the baseline and the stripped build. I used the following CMake command: cmake -G "Sublime Text 2 - Ninja" -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=Yes

This seems to indicate that the idea is a workable solution to your use case. We've still got some bikesheds to get through. (And I don't consider myself a good reviewer for Clang in this, so we need to identify who is.) As background to this extension idea, let me say that I prefer the notion that developers, particularly perf-aware developers like gamedevs, will want to handle PGO via

> On Dec 23, 2014, at 9:45 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 22, 2014, at 2:56 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> Circling back to Chandler on file size differences. Here are the highlights of what is different. >> >> For my analysis I built LLVM and Clang using a clang built with my

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

Hello LLVM community, Over the last few years the LLVM team here at Apple and development teams elsewhere have been busily working on finding new and interesting uses for LLVM. Some of these uses are traditional compilers, but a growing number of them aren’t. Some of LLVM’s new clients, like WebKit, are embedding LLVM into existing applications. These embedded uses of LLVM have their own unique

Alright, this version works for me. Anything else that needs to be done? -Alex > On Oct 7, 2015, at 8:15 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake > index 452a728..cb06450 100644 > --- a/cmake/modules/TableGen.cmake > +++ b/cmake/modules/TableGen.cmake > @@ -70,6 +70,15 @@

> On Aug 26, 2016, at 3:22 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 26 August 2016 at 22:45, Chris Bieneman via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Recently, I’ve made a handful of new changes that actually make it useful, and I wanted to blast out this update and encourage people to give it a try. > > Woot! Compiling RT as we

Looks good to me! I can commit this for you today. Thanks! -Chris > On Oct 19, 2015, at 2:40 PM, Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Looks like the LLVMSupport patch didn't get everything -- build failed in the > same way on libLLVMTableGen. Problem/solution looked the same as for > LLVMSupport, so just tweaked the previous patch, and

It should probably be inside an `if(LLVM_USE_HOST_TOOLS)` block. That way the extra target and command won’t get added unless needed and CMake won’t spew dev warnings. Adding a target with a nonexistent dependency makes CMake dump a bunch of developer warnings. Other than that this looks good. Does it resolve the issue for you? -Chris > On Oct 7, 2015, at 4:09 PM, Alex Wang <aw1621107 at

Sadly I really can’t help you debug the home-brew build, it is a good ways outside my expertise. If you want to try building from source using the guide here: http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary <http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary> I’d be more helpful. As it is, the patch you proposed doesn’t seem to make it

> On Dec 23, 2014, at 10:54 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > >> On Dec 23, 2014, at 10:41 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote: >> >> On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >>>>> It should be

> On Oct 5, 2015, at 9:37 AM, Alex Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Probably should have checked earlier... Do patches go directly to llvm-commits for review instead of getting reviewed here first? > > ccing llvm-commits too in case >> On Oct 4, 2015, at 8:20 PM, Alex Wang <aw1621107 at gmail.com> wrote: >> >> Alright, got

The behavior here is consistent with setting SDKROOT in the environment to an OS X SDK. -Chris > On Sep 22, 2015, at 2:28 PM, Alex Wang <aw1621107 at gmail.com> wrote: > > Logs + commands added to the earlier gist. > > Only thing different from a plain trunk build is adding -Wl,-v and -Wl,-t to the > iossim link flags. > >> On Sep 22, 2015, at 5:17 PM, Chris

Alright, got something thrown together. Here it is inline (also attached if that's more convenient): diff --git a/cmake/modules/TableGen.cmake b/cmake/modules/TableGen.cmake index 452a728..be6729d 100644 --- a/cmake/modules/TableGen.cmake +++ b/cmake/modules/TableGen.cmake @@ -107,9 +107,18 @@ macro(add_tablegen target project) endif() set(${project}_TABLEGEN_EXE