similar to: [LLVMdev] Changing Endian in TargetData

No luck there with modifying clang/lib/Basic/Targets.cpp unfortunately. I only modified BigEndian to 'true' and Builder.defineMacro to "__BIG_ENDIAN__" On Sat, Jul 7, 2012 at 2:34 AM, Anton Korobeynikov <anton at korobeynikov.info>wrote: > > Oh sorry, clang. > Then you should modify clang, not backends, look into Basic/Targets.cpp > there. > > PS: Note

> Even if I'm only looking at the ir and emit-llvm? Ah, sorry, I misread your email. How you're producing the IR then? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

> -S -emit-llvm >From what? clang? llvm-gcc? dragonegg? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

HI, Developers: I linked libLTO.so in $LLVMROOT/Debug/lib however, my program crashes in assertion at 149line [Pass.cpp] void RegisterPass(const PassInfo &PI) { bool Inserted = PassInfoMap.insert(std::make_pair(PI.getTypeInfo(),&PI)).second; assert(Inserted && "Pass registered multiple times!"); } i confirm that there is only one static variable

Victor Zverovich wrote: > Dear all > > I am trying to get the size of an LLVM pointer type. > getPrimitiveSizeInBits() returns 0 for it and the documentation for > isSized() suggest to use TargetData. > I figured out from Kaleidoscope example that one can get a pointer to > TagetData object through the execution engine but it seems to be an > overkill. > What is the

For those targets supported by LLVM, you can get their TargetData by creating TargetMachine first (take X86 as example): ==== BEGIN CODE SNIPPET ==== const std::string TripleStr = "i686-unknown-linux"; // hard coded for example const std::string FeatureStr = ""; // hard coded for example std::string Err; const Target* T; TargetMachine* TM = NULL; const

I've tried to build something that wanted ms-extensions on OpenBSD. Long story short, didn't work so well, because all system includes lead to <machine/_types.h> #ifndef __cplusplus typedef int __wchar_t; #endif and since ms-extensions includes __char_t as a built-in, this did fail abysmally. It would be simple to fix in OpenBSD, assuming clang did tell us it

Here is my patch for it: Index: ReleaseNotes.html =================================================================== --- ReleaseNotes.html (revision 166627) +++ ReleaseNotes.html (working copy) @@ -669,6 +669,9 @@ "TargetTransformInfo" provides a number of low-level interfaces. LSR and LowerInvoke already use the new interface. </p> +<p> The TargetData structure

Is there a way to create a default TargetData for the current host? Currently I have to create a module and then create a TargetData from that. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail. -------------- next part -------------- A non-text attachment

LGTM for this bit. On Oct 25, 2012 7:52 AM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Here is my patch for it: > Index: ReleaseNotes.html > =================================================================== > --- ReleaseNotes.html (revision 166627) > +++ ReleaseNotes.html (working copy) > @@ -669,6 +669,9 @@ > "TargetTransformInfo"

On Fri, May 12, 2017 at 12:01:35PM +0200, Dimitry Andric wrote: > On 11 May 2017, at 20:04, Marc Espie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > I've tried to build something that wanted ms-extensions on OpenBSD. > > Long story short, didn't work so well, because all system includes > > lead to > > > > <machine/_types.h>

The attached patch makes DeadStoreElimination able to remove stores in store-store dependencies when the operand types are equal, even if there is no TargetData available. / Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: DeadStoreElimination.patch Type: text/x-patch Size: 812 bytes Desc: not available URL:

Re-posting with better-looking code. Hans Wennborg wrote: > The attached patch makes DeadStoreElimination able to remove stores in > store-store dependencies when the operand types are equal, even if there > is no TargetData available. > > / Hans > > > ------------------------------------------------------------------------ > >

Sorry, I admit my e-mail was a bit unclear. Here is an example: declare void @foo() define void @f(i32* noalias %p) { store i32 1, i32* %p; <-- This is dead call void @foo() store i32 2, i32 *%p ret void } When run through ./llvm-as test.ll -o - | ./opt -O3 -S the dead store is not removed by the DSE pass. (The call to @foo is there to prevent InstCombine

On Mar 9, 2011, at 8:40 AM, Duncan Sands wrote: > Hi Fabian, > >> I am somewhat confused by the following method within the LLVM, >> especially the lines >> "confusion starts" -> "confusion ends" are hard to follow. > > yes, this seems like a wart. It has been there ever since Chris added the > getPreferredAlignmentLog method in commit

On Feb 20, 2009, at 3:05 PM, David Greene wrote: > On Wednesday 18 February 2009 21:43, Dan Gohman wrote: >> I agree, that doesn't look right. It looks like this >> is what was intended: >> >> Index: lib/CodeGen/SelectionDAG/DAGCombiner.cpp >> =================================================================== >> ---

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

Hi Fabian, > I am somewhat confused by the following method within the LLVM, > especially the lines > "confusion starts" -> "confusion ends" are hard to follow. yes, this seems like a wart. It has been there ever since Chris added the getPreferredAlignmentLog method in commit 25978. Maybe he can comment on whether the code to bump up the alignment for big

On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote: > Now that 2.5 is about to branch, I'd like to bring up one of Scott's > favorite topics: certain optimizers widen or narrow arithmetic, > without regard for whether the type is legal for the target. In his > specific case, instcombine is turning an i32 multiply into an i64 > multiply in order to eliminate a cast. This

On Oct 27, 2008, at 3:14 AM, Jay Foad wrote: >>> I'm already working on this myself. Would you be interested in >>> having >>> this work contributed back to LLVM? >> >> If this were to better support target independent languages, it would >> be very useful. If you're just trying to *reduce* the endianness >> assumptions that leak