search for: libtarget

...tly executing > (__tgt_rtl_run_target_region() )? Is this implementation defined? I’m > certainly ok with that answer, but I believe we need to explicitly state > what the behavior is. > In my view the user-visible OpenMP calls that apply to target regions depend on the state kept in libtarget.so, and are therefore device-type independent. What is device dependent is how the OpenMP terminology is mapped. For example, get_num_teams() would operate on top of the state kept in libtarget.so but how the device interpret a team is device dependent and deviced by the target dependent runtime....

...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. Similarly, the functions in lib/Target/TargetRegisterInfo.cpp happen to not depend on libCodeGen, but I don't think the TRI interface has anything to offer to a libTarget client that doesn't link libCodeGen as well. AFAICK, TargetMachine.cpp doesn't depend on either of these classes....

...odeGen? > > 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. > > Similarly, the functions in lib/Target/TargetRegisterInfo.cpp happen to not depend on libCodeGen, but I don't think the TRI interface has anything to offer to a libTarget client that doesn't link libCodeGen as well. The original idea of the Target* classes is that they represen...

...something like TM.getCGContext(Function). > > This sounds like you want IR-level passes which have direct, hard dependencies on the target and codegen. That would be a radical departure from the core design of the IR / MI separation. 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. Either way, we need an IR-level API that requires subtarget initialization. It should be explicit which passes do and don’t require the subtarget. This would add *a lot* of clarity to the role of CodeGenPrepare-style...

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 >

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

...>> >> 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. >> >> Similarly, the functions in lib/Target/TargetRegisterInfo.cpp happen to not depend on libCodeGen, but I don't think the TRI interface has anything to offer to a libTarget client that doesn't link libCodeGen as well. > > The original idea of the Target* classes is...

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 at all. Yes, there is CodeGenPrepare which violates...

...arget > > I was thinking of directly replacing X86Subtarget as such: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> TargetMachine > (provides) -> CGContext > > So CGContext could still live inside libTarget. CGContext would be > initialized for a Function based on the attributes and the information > already in its container, TargetMachine. > > It sounds like you would be making CGContext part of libCore instead, like > this: > > IR Transform > (links with) -> LLVMContext...

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 explicit list of dependencies somewhere, you might want to update it as well (and different target-specific places in CMakeList.txt files). -- With best regards, Anton Korobeynikov Faculty of Mathematics an...

...> >>> 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. >>> >>> Similarly, the functions in lib/Target/TargetRegisterInfo.cpp happen to not depend on libCodeGen, but I don't think the TRI interface has anything to offer to a libTarget client that doesn't link libCodeGen as well. >> >> The original idea of the Tar...

...call) -> X86TTI (links with) -> X86Subtarget I was thinking of directly replacing X86Subtarget as such: IR Transform (links with) -> TargetTransformInfo (dynamic call) -> X86TTI (links with) -> TargetMachine (provides) -> CGContext So CGContext could still live inside libTarget. CGContext would be initialized for a Function based on the attributes and the information already in its container, TargetMachine. It sounds like you would be making CGContext part of libCore instead, like this: IR Transform (links with) -> LLVMContext (provides) -> CGContext CGCont...

...t is used to model things that are target specific (which is why I made the mistake of putting it where it is, and why other people continue to be confused by it) but it really is a completely different concept than what Nadav is talking about for getting cost information. The stuff at the "libtarget level" are meant to be subclassed by targets, and are needed to specify things that vary based on context and are not capable of being serialized into a string. Consider a query like "how expensive is a shuffle with this type on this shuffle mask". Clearly the only way to implement...

...es (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 "libsupport.a" and "libtarget.a". None of the .o files are shared objects, they're just regular relocatable object files. Is there some documentation on what is in each of these .o and .a files? Is there some aversion to using shared objects? Platform=Linux (RedHat 9) Compiler=GCC 3.3.1 Reid. P.S. I noticed that...

...et > > I was thinking of directly replacing X86Subtarget as such: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> TargetMachine > (provides) -> CGContext > > So CGContext could still live inside libTarget. CGContext would be > initialized for a Function based on the attributes and the information already in its container, TargetMachine. > > It sounds like you would be making CGContext part of libCore instead, like this: > > IR Transform > (links with) -> LLVMContext > (pr...

Hi, I'm looking for some pointers on how to troubleshoot this problem. I'm trying to write a backend for the AVR. 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? AVRTargetMachine::AVRTargetMachine(const Target &T,

...d 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? Manually providing nvlink with a -L flag pointing to the appropriate path seems to work for the linking step. Cheers, Roel On 09/06/15 00:07, Samuel Antão wrote: > Hi Roel, Chris, > > This is a summary on h...

...ibrary 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: libtarget.a -> libLLVMTarget.a However, a few of them changed outright to make it consistent: cwriter.o -> LLVMCBackend.o profpaths.o -> LLVMProfilePaths.o Sparcv9Sched.o -> LLVMSparcV9InstrSched.o The changes have all been made to the necessary makefiles in llvm proper, but not in any of the...

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.

...s 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 "libsupport.a" and "libtarget.a". None of the .o files > are shared objects, they're just regular relocatable object files. > Is there some aversion to using shared objects? Hrm, interesting question that. You can currently build shared libraries easily by setting SHARED_LIBRARY=1 in the makefile for a librar...