similar to: [LLVMdev] arm64 / iOS support

Hi, I'm trying to implement a 10-bit relocation that does not start at the beginning of a byte-boundary and I'm not entirely sure I understand the use by some targets of MCFixup.Offset and MCFixupKindInfo.TargetOffset. LLVM's documentation states that: MCFixup.Offset -"/// The byte index of start of the relocation inside the encoded instruction."

This should fix this warning from Visual Studio 2010: 33>..\..\..\llvm-2.8svn-build\lib\MC\MachObjectWriter.cpp(772): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) Index: lib/MC/MachObjectWriter.cpp =================================================================== --- lib/MC/MachObjectWriter.cpp (revision 111120) +++

On Apr 22, 2008, at 4:58 AM, Arnold Schwaighofer wrote: > On Tue, Apr 22, 2008 at 12:30 AM, Evan Cheng <evan.cheng at apple.com> > wrote: >> More nitpicks: >> ... >> No need for else here. :-) > Done >> SPDiff = (int)CallerMinReservedArea - (int)ParamSize; >> >> Just change last statement to >> int SPDiff = (int)... > Done >>

I'm having some troubles building LLVM 3.3 (previously I was using 3.2). I'm getting a lot of errors in the various architecture support: In file included from PPCFrameLowering.h:17:0, from PPCTargetMachine.h:17, from PPCSelectionDAGInfo.cpp:15: PPCSubtarget.h:60:49: error: expected class-name before ‘{’ token PPCSubtarget.h:196:30: error:

Hi all, The goal of this RFC is to make information related to variant scheduling classes accessible at MC level. This would help tools like llvm-mca understand/resolve variant scheduling classes. To achieve this goal, I plan to introduce a new class of scheduling predicates named MCSchedPredicate. An MCSchedPredicate allows the definition of boolean expressions with a well-known semantic, that

On Apr 16, 2008, at 10:07 AM, Arnold Schwaighofer wrote: > Hello Dale, > > this is an updated version of the tail call optimization patch for > powerpc. could you have a look at it? > > i added code to support ppc64 (untested, will try to get access to > ppc64 on a friend's machine). > incorporated evan's formatting suggestions. ;) > > will run another round

On Tue, Apr 22, 2008 at 12:30 AM, Evan Cheng <evan.cheng at apple.com> wrote: > More nitpicks: > ... > No need for else here. :-) Done > SPDiff = (int)CallerMinReservedArea - (int)ParamSize; > > Just change last statement to > int SPDiff = (int)... Done > > +bool > +PPCTargetLowering::IsEligibleForTailCallOptimization(SDOperand Call, > +

Eli, Here is an updated patch. This is a lot smaller based on your feedback and still solves the same problem. For your comment on the IR changes, I'm reluctant to introduce changes there because really the backend is overriding the default behavior at a device specific level. The optimizations themselves can be dangerous, but still should produce correct results, this only allows the

On Fri, Aug 24, 2012 at 4:07 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Villmow, Micah >> Sent: Friday, August 24, 2012 2:56 PM >> To: 'Eli Friedman' >> Cc: LLVM Developers Mailing List >> Subject: RE: [LLVMdev] RFC: Supporting different sized address space >> arithmetic >>

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

Hi, For the function call - yes, probably. But what about branching inside one function (standard if-then for example)? For example: echo "int g() { int a = 1; if (a > 3) return 1; return 0; }" | clang -x c - -o /tmp/a.o -c && objdump -d /tmp/a.o Thanks, Petr On Thu, Jan 19, 2017 at 8:06 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/19/2017 9:11

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

On 7/29/2017 1:28 AM, Dr. ERDI Gergo via llvm-dev wrote: > Hi, > > During instruction selection, I have the following code for certain > LOAD instructions: > > const LoadSDNode *LD = cast<LoadSDNode>(N); > SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), > VT, PtrVT, MVT::Other, > LD->getBasePtr(), LD->getChain()); >

Hi, During instruction selection, I have the following code for certain LOAD instructions: const LoadSDNode *LD = cast<LoadSDNode>(N); SDNode* LDW = CurDAG->getMachineNode(AVR::LDWRdPtr, SDLoc(N), VT, PtrVT, MVT::Other, LD->getBasePtr(), LD->getChain()); // Honestly, I have no idea what this does, but other memory // accessing instructions

Hi all, I'm trying to make an LLVM backend for the Adapteva's Epiphany E16 CPU (used in Parallella board), using CPU0 and some other backends as examples, and I've got stuck with branching. When I'm printing out asm, all branch labels are printed as they should be. But when I'm trying to generate obj file, I'm getting zeros instead of PC-related offset in all branch

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

Hi Sanjoy, > Attached set of patches splits llvm.init.trampoline into an "init" > phase and an "adjust" phase, as discussed on the "Go on dragonegg" > thread. thanks for doing this. The patches look good, though the decomposition into individual patches is not that great (since things won't always work, in fact not even compile I think, with not all

Am Do., 1. Nov. 2018 um 15:21 Uhr schrieb David Greene <dag at cray.com>> > > thank you for sharing the system hierarchy model. IMHO it makes a lot > > of sense, although I don't know which of today's passes would make use > > of it. Here are my remarks. > > LoopDataPrefetch would use it via the existing TTI interfaces, but I > think that's about it

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction