similar to: [LLVMdev] Module->getDataLayout returns std::string instead of DataLayout

I need help. I can't get it to work. I'm crying here, really, I'm balling my eyes out. Is there any way for a beginner to get support with using LLVM? All my queries are just ignored or disregarded on this mailing list. Why isn't there an llvm mailing list for novices? This is the only thing that can get my programming language, to be operation in a reasonable amount of time,

I’m debugging SAFECode source code files, and in AllocatorInfo.cpp, in the function getObjectSize(Value* V), the function getAnalysis<DataLayout>() is called. I’ve run into this problem before, and the first time I saw it, my employer recommended I use M.getDataLayout() instead, where M was a reference to a Module. However, in getObjectSize(Value* V), there is no Module reference in the

It appears llc gives preference to the default target datalayout whereas opt gives preference to the module datalayout. Is there a reason they behave differently? From llc.cpp: // Add the target data from the target machine, if it exists, or the module. if (const TargetData *TD = Target.getTargetData()) PM.add(new TargetData(*TD)); else PM.add(new TargetData(&mod));

On Thu, May 31, 2012 at 10:21 PM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > On Thu, May 31, 2012 at 8:06 PM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 31, 2012, at 2:39 PM, Justin Holewinski wrote: >> >> > The attached patch add the ability to programmatically re-direct >> outs()/errs() to an arbitrary

Chris Lattner <clattner at apple.com> writes: > On Jul 5, 2010, at 3:31 AM, Óscar Fuentes wrote: > >> Chris Lattner <clattner at apple.com> writes: >> >>> On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: >>> >>>> In X86Subtarget.h there is a method `getDataLayout' which selects the >>>> data layout depending on the

Hi everyone, In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) when the symbol is not found : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } return

I needed to be able to update stub pointers for hot functions that get recompiled in a lazy JIT that uses CompileOnDemandLayer. In order to do this I added a method that allows pointers to be updated but does not expose any of the other internals of the COD layer. Does anyone have a cleaner way to do this? Has something to facilitate this already been added? Would it be possible to merge this

Chris Lattner <clattner at apple.com> writes: > On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: > >> In X86Subtarget.h there is a method `getDataLayout' which selects the >> data layout depending on the platform, ignoring whatever the user setted >> with Module::setDataLayout. >> >> What's the rationale for this? > > Data layout is a

On Jul 5, 2010, at 3:31 AM, Óscar Fuentes wrote: > Chris Lattner <clattner at apple.com> writes: > >> On Jul 4, 2010, at 6:43 PM, Óscar Fuentes wrote: >> >>> In X86Subtarget.h there is a method `getDataLayout' which selects the >>> data layout depending on the platform, ignoring whatever the user setted >>> with Module::setDataLayout.

+Lang Hames <lhames at gmail.com>, Master Regent of the Three <No, Two sir> JITs On Thu, Jul 28, 2016 at 12:31 PM Sean Ogden via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I needed to be able to update stub pointers for hot functions that get > recompiled in a lazy JIT that uses CompileOnDemandLayer. In order to do > this I added a method that allows pointers to

Eric Christopher wrote: > How are you trying to call it? Do you have a DataLayout? In test/Analysis/ValueTracking/memory-dereferenceable.ll, just change byval to dereferenceable(8), and %dparam won't match (see lib/IR/Value.cpp:521 for the logic that is supposed to fire). How do I get it to pass? I tried introducing a target-triple and target-datalayout, but it didn't help.

In X86Subtarget.h there is a method `getDataLayout' which selects the data layout depending on the platform, ignoring whatever the user setted with Module::setDataLayout. What's the rationale for this?

On Jul 5, 2010, at 10:24 AM, Óscar Fuentes wrote: >> I'm not opposed to having it fail when something semantic (like the >> alignment of double) is wrong. The hints like the 'native integer >> types' should not cause it to fail. > > Then I guess that the information provided by the user through > Module::setDataLayout is used in some places instead of the

Hi, I'm seeing a bug in the AVR backend that seems to be caused by LLVM thinking things will be aligned to 8 bytes whereas they are unaligned. Specifically, MF->getDataLayout().getPrefTypeAlignment(Ty) returns 8 for the following two types: %opt = type { i8, [0 x i8], [3 x i8] } %Machine = type { i16, [0 x i8], i16, [0 x i8], [16 x i8], [0 x i8] } The target datalayout specifies that

Hi Sean, This is great, but it couples LogicalDylib too tightly to CompileOnDemandLayer. Does this alternative implementation of getLogicalModuleResourcesForSymbol work for you (unfortunately I don't have a local test case for this yet): LogicalModuleResources* getLogicalModuleResourcesForSymbol(const std::string &Name, bool

Hello, I'm migrating to samba4 (samba 4.0.2 in Debian 6.0.6) After copying .tdb files and smb.conf and migrating ldap server to the new server and configured it. When I run: /usr/loca/samba/bin/samba-tool domain classicpugrade --dbdir=samba --user-xattrs=yes --realm=sadom.espel.com samba/smb.conf I get: Reading smb.conf WARNING: The "idmap backend" option is deprecated WARNING:

On Thu, 2 Mar 2006, Chris Lattner wrote: >> Any ideas what could be wrong? > > Sorry for the delay, please try this tarball: > http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz Actually, do to a recent change in CVS, this tarball will probably not work anymore. Please apply the attached (small) patch on top of it in the gcc directory. Worth noting, this front-end only works

It does work. I just tested it on my JIT. Thanks! As for the part that couples them too tightly, would you recommend I just keep my own specialized version of CompileOnDemandLayer.h that includes this functionality, or do you have any ideas for a cleaner way to do this? I've noticed a couple of people asking for support for updating stub pointers for functions that are optimized at runtime,

hi, with LLVM 3.1, i am trying to compile toy.cpp from http://llvm.org/docs/tutorial/LangImpl7.html#code. i got the following error: $ clang++ -g toy.cpp `llvm-config --cppflags --ldflags --libs core jit native` -O3 -o toy toy.cpp:4:10: fatal error: 'llvm/IRBuilder.h' file not found #include "llvm/IRBuilder.h" i fixed this by modifying the broken line to: #include

Hi Sean, As for the part that couples them too tightly, would you recommend I just > keep my own specialized version of CompileOnDemandLayer.h that includes > this functionality, or do you have any ideas for a cleaner way to do this? My apologies - I wasn't very clear in my description of the issue. The only sense in which your original patch was tightly coupled was that it had