similar to: [LLVMdev] Libraries? What Libraries?

On Mon, 2 Feb 2004, Reid Spencer wrote: > I'm trying to figure out which LLVM libraries (er.. object files that > is) I should link with my programs. It isn't clear to me what the build > output of LLVM is. I tried the new make "install" target and got a > plethora of .o files. The few .a files I got had _likely_to_conflict_ > names such as

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 John, Thank you for the comments. I am addressing some of them bellow. Regards, Samuel 2014-08-11 9:36 GMT-04:00 John Leidel (jleidel) <jleidel at micron.com>: > Sergey [et.al], thanks for putting this proposal together. Overall, this > looks like a pretty solid approach to providing relatively hardware > agnostic omp target functionality. I had several comments/questions

Hi, Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTarget.

On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? > > TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen

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 Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >> >> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most

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) ->

Hello, John > There is an undefined reference at line 48 which is the line FrameInfo() is > on. I've tried to use the MSP430 and other targets as references so I'm not > sure > what changes I did would cause a problem on this line? It doesn't seem you're linking libTarget in. Have you tried not to use cmake-generated makefiles? As for the cmake - it tracked the

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 Oct 5, 2012, at 2:11 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Is it possible to not make it 'Target*'? I'm spending a lot of time moving TargetData out, would hate to have to do it again at some point in the future for TargetVectorData. :) There is an important difference here (and a common point of confusion) between TargetData and the the stuff

Hello everybody! I would like to present a proposal for implementation of OpenMP offloading in LLVM. It was created by a list of authors and covers the runtime part at most and at a very high level. I believe it will be good to have input from community at this early stage before moving deeper in details. The driver part is intentionally not touched, since we have no clear vision on how one can

On Sat, 9 Sep 2006, Michael McCracken wrote: >> No, gfortran in gcc 4.0 is, ehm, highly experimental (read: a piece of >> junk). Gfortran in gcc 4.1 was the first one that worked for NIST (and >> for SPEC). > > Hm. I had noticed a bunch of changes in the current sources, but had > hoped 4.0.1 wasn't too far behind. This is discouraging. So, it sounds > like it

On Nov 27, 2012, at 11:51 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >>> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen?

Since I'm trying to get LLVM ready for commercial use, it was prudent to ensure that our library names do not conflict with any others upon installation. So, all the librarys have had two renaming changes made: 1. They are all prefixed with LLVM 2. They use upper and lower case to match the library directory they came from. In general they should be recognizable to you. For example:

I'm used to Debian-based distros which have a tempfile(1) utility for safely and sanely creating temporary files. There isn't a comperable utility for RHEL/CentOS systems. I've been exercising Google-fu looking for a good robust tempfile generation idiom, but haven't turned one up yet. Hence this appeal to the lazyweb. -- Dr. Ed Morbius, Chief Scientist / | Robot

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

Hi Sergos and Samuel, Thanks for the links, I've got it mostly working now. I still have a problem with linking the code. It seems that the clang driver doesn't pass its library search path to nvlink when linking the generated cuda code to the target library, resulting in it not correctly finding libtarget-nvptx.a. Is there some flag or environment variable that I should set here?

On 9/11/06, Chris Lattner <sabre at nondot.org> wrote: > On Sat, 9 Sep 2006, Michael McCracken wrote: > >> No, gfortran in gcc 4.0 is, ehm, highly experimental (read: a piece of > >> junk). Gfortran in gcc 4.1 was the first one that worked for NIST (and > >> for SPEC). > > > > Hm. I had noticed a bunch of changes in the current sources, but had >