similar to: amount of camelCase refactoring causing some downstream overhead

During that variable renaming debate, there was a discussion about discussion about doing things all at once, piecemeal or not at all. An issue that wasn't really resolved I think. I had the impression that the efforts fizzled out a bit, and I thought this renaming was maybe related to that, but I'm neutral on if we should do variable renaming. All I'm asking as a kindness if we could

I don't think anyone is arguing to change longstanding policy. From a downstream perspective many small renaming changes do increase overhead for us. One thing that happens to downstream projects is that they support more than one LLVM version, we (JuliaLang) currently try to support latest stable + master. So for me the question is more, are renaming changes worth downstream projects not

Hi Philip, While it's true we don't I think Valentin is reasonable in saying "hey, when people do this let's try to combine them if it makes sense". It's just being polite to everyone, especially if it doesn't risk the patches or upstream stability. I don't think there's a policy change being proposed, just a "hey, let's see what we can do in the

Hi Philip, I think you might be reading more into the suggestion/discussion than is actually there. * I do not want upstream developers "trying to be polite" if that delays otherwise worthwhile work. Nobody suggested that. It’s perfectly possible to “be polite” and still not delay worthwhile work. * The current policy is "downstream is on their own". Nobody

Hi Mehdi! I think the value to upstream (of doing mass reformatting in fewer commits) has to do with the intrusion of nonfunctional commits into `git blame` kinds of research. Every line that someone touches for a formatting reason necessarily obscures the history of functional changes in that block of code. The fewer of those that people have to work around, the better. I admit this is a

> On May 5, 2020, at 2:45 PM, Ties Stuij <Ties.Stuij at arm.com> wrote: > > Quentin: Thanks for the info. I was under the impression that the LLVM community at large would prefer to extend the IR type to a bfloat MVT type. I've made a number of patches to implement this up to a point for AArch64. I can post those on Phab and start a thread to sample opinions. Sounds good to

I don’t think bfloat should be handled this way. What Amara is suggesting is an optimization, i.e., if we drop the information we are still correct. With bfloat, if we do an operation on float16 instead of bfloat16 this is a correctness problem. So that means that either we need to have new opcodes for bfloat or we need to carry around the floating point type in MIR. I think it would be more

Hi everyone, I have a code style question: should full test programs (.c,.cpp files) use the documented CamelCase from http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly or instead use lower_with_underscores as I've been told the .ll lit test files should use? I see both in existing files, and in particular for projects/compiler-rt I cannot

Just in case it interests anyone else, I'm playing around with trying to broaden the MCStreamer API to allow for emission of bytes without copying the contents into a local buffer first (either because you already have a buffer, or the bytes are already present in another file, etc) in http://reviews.llvm.org/D17694 . In theory there's some overlap with lld here (no doubt it already does

On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com> wrote: > > On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Just in case it interests anyone else, I'm playing around with trying to > broaden the MCStreamer API to allow for emission of bytes without copying > the contents into a local buffer first (either because

Hi David, The way I imagined that we might want to extend the MCStreamer API (this was motivated by DIEData) is by allowing clients to move bytes and fixups into the MC layer. This is the sort of API that I was imagining: void MoveAndEmitFragment(SmallVectorImpl<char> &&Data, SmallVectorImpl<MCFixup> &&Fixups); Note that this mirrors the

> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > Just in case it interests anyone else, I'm playing around with trying to broaden the MCStreamer API to allow for emission of bytes without copying the contents into a local buffer first (either because you already have a buffer, or the bytes are already present in another file, etc) in

On Mon, Feb 29, 2016 at 3:51 PM, Adrian Prantl <aprantl at apple.com> wrote: > > On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com> wrote: > >> >> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >>

> On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Just in case it

> On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:36 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Feb 29, 2016, at 3:18 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> Just in case it

> On Feb 29, 2016, at 4:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Feb 29, 2016 at 3:51 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote: > >> On Feb 29, 2016, at 3:46 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On

On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > This is a brain-dump of my thoughts on the MCStreamer interface after several > days of digging around trying to get a COFF writer working. Great! Something that is worth pointing out is that the MCStreamer API is intended to directly reflect what is happening in .s files. We basically want one MCStreamer callback to correspond to one

This is a brain-dump of my thoughts on the MCStreamer interface after several days of digging around trying to get a COFF writer working. All fragments should be associated with a symbol. For assembler components, a unnammed "virtual" symbol can be used when there is no explicit label defined. Section assignment should be the responsiblity of the object imlementing the MCStreamer

I compile these two lines in llc @tst1 = internal global [4 x i8] zeroinitializer; @tst2 = internal global [4 x i8] [i8 0, i8 1, i8 2, i8 3]; @tst1 is emited via MCStreamer::EmitCommonSymbol while the other is emited via MCStreamer::EmitLabel followed by MCStreamer::EmitBytes from what I can tell, only symbols with common linkage should me emitted by MCStreamer::EmitCommonSymbol, is this the

On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one > statement in the .s file. This makes it easier to handle from the compiler > standpoint, but is also very important for the llvm-mc assembly parser > itself. > > This