similar to: [LLVMdev] Renaming MCInstFragment to MCRelaxableFragment

I guess that is OK, but wouldn't it be better to also rename MCDataFragments then? On 2 January 2013 12:25, Eli Bendersky <eliben at google.com> wrote: > Hello and happy 2013, > > Would anyone object to renaming MCInstFragment to MCRelaxableFragment? > I believe the latter expresses this class's purpose much more clearly > and avoids the confusion with MCDataFragments

On Thu, Jan 3, 2013 at 11:31 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I guess that is OK, but wouldn't it be better to also rename > MCDataFragments then? > I don't know what a more suitable name would be. Any ideas? Eli

> I don't know what a more suitable name would be. Any ideas? I initially thought MCRelaxedFragment would go well with MCRelaxableFragment, since a MCRelaxableFragment is merged into a MCRelaxedFragment once we are done relaxing it. The problem is that both names are really similar. > Eli Cheers, Rafael

Proposal for ELF text and data big endian support for direct object generation Unless I am mistaken, currently big endian support in the MC layer for ELF direct object generation is limited to ELF headers and tables like relocations. Text and data section contents are still generated as individual bytes. It looks as if the effort was started, but never completed. The proposal is to extend the

Hi Jack, Everything should be already using the sized Emit* routines directly rather than outputting individual bytes of larger entities piecemeal. Have you found that not to be the case? The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform:

Jim, I see routines that are already available to do the endianizing, but the data and text section contents don't have sizing for the individual elements as far as I can see so that I can endianize them. That is the part I am trying to solve, not the bit twiddling algorithm. Did I miss something? Jack ________________________________________ From: Jim Grosbach [grosbach at apple.com] Sent:

Hi Jack, I would have expected the Mips backend to be using these routines (or more likely something on top of them) to emit the contents of the data and text sections and thus have the bit-twiddling done by these routines. I take it that's not happening? Basically, this should already work without any additional infrastructure. If it's not, something is broken and bypassing the

Moving to LLVM dev to discuss the possibility of extending the cast infrastructure to handle this. On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: > On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >> TypeLoc casting looks bogus. >> >> TypeLoc derived types return true from classof when the dynamic type >>

On Thu, Nov 29, 2012 at 3:49 PM, David Blaikie <dblaikie at gmail.com> wrote: > Moving to LLVM dev to discuss the possibility of extending the cast > infrastructure to handle this. > > On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: >> On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> TypeLoc

On Wed, Oct 20, 2010 at 2:56 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Gosh, this is taking a while :-) >> Is there anything else I missed? > > Another one I noticed. Instead of > >      SmallString<32> *FC = &currFileFragment.getContents(); >      (*FC) += static_cast<char>(attr); >      (*FC) += static_cast<char>(0xFF

Hello, I've been trying to add support to the integrated assembler to handle cases like below foo:instr; .if . - foo; instr; .endif when the dot symbol and foo are assigned to consecutive MCDataFragments <https://github.com/ClangBuiltLinux/linux/issues/744>. I have a patch <https://reviews.llvm.org/D6941> under review. And even though it seems to solve the problem, the concern

Hi Michael, Overall patch looks good. I do have a few comments below. My main comment is please try to make the style match that used in the MCMachOStreamer more closely. I intend to refactor more functionality into the base MCObjectStreamer class, and having them use consistent idioms makes this easier; specific instances are included in the comments: -- > diff --git

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

> Hmm, I wish we had this discussion way earlier.. > > How would I emit things in different subsections? I can do a high > level switch to .ARM.attributes, and if I were emitting one blob from > begin to end, using the higher level interface would be preferable, > but it contains additional subsections - which are naturally > represented by MCDataFragments - Is there an MC

I'm running into some pretty bad performance in llc.exe when compiling some large neural networks into code that contains some very large llvm::ConstantDataArrays, some are { size=102,760,448 }. There's a small about of actual code for processing the network, but the assembly is mostly global data. I'm finding that llc.exe memory spikes up around 30 gigabytes and the job takes 20-30

On Thu, Oct 21, 2010 at 7:50 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Hmm, I wish we had this discussion way earlier.. >> >> How would I emit things in different subsections? I can do a high >> level switch to .ARM.attributes, and if I were emitting one blob from >> begin to end, using the higher level interface would be preferable,

Hi Hal, Thanks for the reference. I’ve looked at PPCBranchSelector and the PowerPC backend. It is very different from the X86 architecture and unfortunately the way branch relaxation and alignment related issues are handled in PPC cannot be copied to X86. This is because: 1. PPC instructions are of fixed length while X86 instructions are of variable length, and their length can change

Hello, The recent renamings moved some IR-related files and directories to more logical places. Is there a plan to rename lib/AsmParser as well? This directory name is somewhat misleading, because the code in it parses IR. In fact, nothing mentions AsmParser in the code inside that dir, except the build files. The name creates a confusion with other AsmParser citizens of LLVM like

Can someone show me how to modify one (R.oo) class's object inside another (R.oo) class's method? Is that possible with the R.oo package? A quick example or reference to an example would be outstanding... Thanks, Ben [[alternative HTML version deleted]]

On Fri, Sep 6, 2013 at 9:35 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi Eli > > I don’t know a workaround which will keep support for coloured terminal > output, but if you can live without it then passing these to configure > should work. > > --enable-curses=no > --enable-terminfo=no > > Re-doing the configure & build in a new directory solved