similar to: [LLVMdev] [RFC] CGContext skeleton implementation

On Mon, Dec 2, 2013 at 4:25 PM, Andrew Trick <atrick at apple.com> wrote: > > On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > Hello llvm-dev, > > > > Following up on the "CodeGen Context" discussion that was started, > attached is patch which implements a pretty minimal skeleton of a CGContext > implementation.

On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Hello llvm-dev, > > Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to be made available to codegen so that codegen

On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > Hello llvm-dev, > > Following up on the "CodeGen Context" discussion that was started, attached is patch which implements a pretty minimal skeleton of a CGContext implementation. The goal is to allow the newly added subtarget attributes on functions to be made available to codegen so that codegen

On Jan 6, 2014, at 10:10 AM, Chandler Carruth <chandlerc at google.com> wrote: > Trying to bubble way back to the top, Andy, do you think there is anything else that needs to be done here before it can go in? I feel like most of our discussion centered around future work, and I'd like to unblock the immediate work to support subtarget-specific code generation. Do we have a solution

On Dec 5, 2013, at 3:19 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > > On Mon, Dec 2, 2013 at 4:25 PM, Andrew Trick <atrick at apple.com> wrote: > > On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > Hello llvm-dev, > > > > Following up on the "CodeGen Context" discussion that was started,

On Jan 6, 2014, at 11:02 AM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, Jan 6, 2014 at 1:42 PM, Andrew Trick <atrick at apple.com> wrote: > On Jan 6, 2014, at 10:10 AM, Chandler Carruth <chandlerc at google.com> wrote: > >> Trying to bubble way back to the top, Andy, do you think there is anything else that needs to be done here before it

On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <atrick at apple.com> wrote: > We currently have something that looks like: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> X86Subtarget > > I was thinking of directly replacing X86Subtarget as such: > > IR Transform > (links with) ->

On Dec 5, 2013, at 4:47 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <atrick at apple.com> wrote: > We currently have something that looks like: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> X86Subtarget > > I was thinking of

On Thu, Dec 5, 2013 at 5:04 PM, Andrew Trick <atrick at apple.com> wrote: > Right. On the flip side, some passes should be able to make hard queries > against target/subtarget that fail if the driver doesn’t initialize them. I > don’t want any way to accidentally run the vectorizer or LSR without > initializing my subtarget info. Also, I want to prevent early passes from >

On Dec 5, 2013, at 5:14 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Dec 5, 2013 at 5:04 PM, Andrew Trick <atrick at apple.com> wrote: > Right. On the flip side, some passes should be able to make hard queries against target/subtarget that fail if the driver doesn’t initialize them. I don’t want any way to accidentally run the vectorizer or LSR without

On Thu, Dec 5, 2013 at 7:36 PM, Andrew Trick <atrick at apple.com> wrote: > It might nice if scalaropts did not need to link against libTarget—we > could easily avoid introducing more dependence on libTarget if that’s a > goal. > We already have that state today in the overwhelming majority of the cases. The pass manager built by the PassManagerBuilder doesn't need a target

Hi all, This is my proposal for how to solve the problem we have with function attributes that affect code generation changing between functions. (This is mostly a problem for LTO.) Please take a look at this proposal, and let me know if you have any questions or comments. Cheers! -bw CodeGen Context =============== The back-end's

On Oct 12, 2013, at 1:55 AM, Bill Wendling <isanbard at gmail.com> wrote: > Hi all, > > This is my proposal for how to solve the problem we have with function attributes that affect code generation changing between functions. (This is mostly a problem for LTO.) > > Please take a look at this proposal, and let me know if you have any questions or comments. > > Cheers!

Is it possible to see the source code of the open-sourced SVML? The diff file does not include the library. I searched the Internet but I could not find. Regards, Naoki Shibata On 2016/07/15 13:55, Tian, Xinmin wrote: > Naoki, > > Intel is planning open-source SVML library (most of them if it not 100%), 6 functions of SVML are open sourced for GCC and LLVM already. But, Intel SVML

I've been working on adding AVX to LLVM and have run across a number of questions. Here's the first one. In some ways AVX is "just another" SSE level. Having AVX implies you have SSE1-SSE4.2. However AVX is very different from SSE and there are a number of sub-features which may or may not be available on various implementations. So right now I've done this: def

On Oct 13, 2013, at 2:35 PM, Bob Wilson <bob.wilson at apple.com> wrote: > On Oct 12, 2013, at 1:55 AM, Bill Wendling <isanbard at gmail.com> wrote: > >> CGContext :: >> >> A central repository for back-end objects. The back-end objects may change, so >> they should not be "cached" by individual passes. This is analogous to the >>

On Oct 13, 2013, at 8:23 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Oct 13, 2013, at 2:35 PM, Bob Wilson <bob.wilson at apple.com> wrote: > >> On Oct 12, 2013, at 1:55 AM, Bill Wendling <isanbard at gmail.com> wrote: >> >>> CGContext :: >>> >>> A central repository for back-end objects. The back-end objects may change,

I've been investigating what is needed to ensure command line options are passed to the backend codegen passes during LTO and enable compiling different functions in a module with different command line options (see the links below for previous discussions). http://thread.gmane.org/gmane.comp.compilers.llvm.devel/78855 http://thread.gmane.org/gmane.comp.compilers.llvm.devel/80456 The command

On Fri, Dec 15, 2017 at 5:30 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Are there reasons why we might not want to do this? Other options we should > consider? It does make the TargetMachine -> TargetIRAnalysis path less abstract, but given that all targets have the same pattern of instantiating a TargetIRAnalysis with a Function->TargetTransformInfo hook, the abstraction does

Current sources (git-b1b6caf) were compiled with GCC 4.8.2 and GCC 4.9.0 with various -msseN options (the default is -msse2). Then I took two WAV files (one is 16-bit and the other is 24-bit) and compressed them using best compression mode. The results are in the table below. (please remember that the resulting value is an encoding time, not encoding speed) CPU: Intel Core i7 950 (up to SSE4.2)