search for: stuij

> 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...

...are that they could save some pain in a simple way. Especially if indeed there is going to be a big renaming push and this would be a continuous thing. Cheers, /Ties ________________________________________ From: Michael Kruse <llvmdev at meinersbur.de> Sent: 17 February 2020 21:16 To: Ties Stuij Cc: llvm-dev Subject: Re: [llvm-dev] amount of camelCase refactoring causing some downstream overhead My understanding is that LLVM's general policy is to not let downstream slow down upstream development. The C++ API explicitly unstable. Note that we are even considering renaming variables g...

...osal to balance the competing interests at hand. > > If anyone is curious, I'm happy to share some ideas offline on what > starting points might be, but I have neither the time nor the interest > to drive such a conversion on list. > > Philip > > On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: > > 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 though...

...terests at hand. >> >> If anyone is curious, I'm happy to share some ideas offline on what >> starting points might be, but I have neither the time nor the interest >> to drive such a conversion on list. >> >> Philip >> >> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: >> > 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 b...

Hi there, At the end of last week we saw a number of commits go in that were camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. For example: - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 Unfortunately all these

...n MIR. I think it would be more manageable to have the floating point type long term. That said, it also depends on what we decide to do at the IR level. For instance, if bfloat support in the IR is limited to intrinsics, we wouldn’t need to go down that road. > On May 5, 2020, at 4:19 AM, Ties Stuij via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I don't know too much about GlobalIsel, but I'm working on adding a new bfloat IR/MVT type (16-bit float type) to LLVM, and on one of the patches Amara raised the issue what we would to to disambiguate between a half and a bf...

...re some very careful drafting of proposal to balance the competing interests at hand. If anyone is curious, I'm happy to share some ideas offline on what starting points might be, but I have neither the time nor the interest to drive such a conversion on list. Philip On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: > 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...

...re some very careful drafting of proposal to balance the competing interests at hand. If anyone is curious, I'm happy to share some ideas offline on what starting points might be, but I have neither the time nor the interest to drive such a conversion on list. Philip On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote: > 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...

Hi, GlobalISel currently drops all type information relating to the integer/FP distinction during the IR translation pass, as the LLT types only represent whether a value is a scalar/vector/pointer and it’s size/shape. To compensate, later passes use the FP operations on those values to guess what kind of value is being stored within that virtual register. This means that i32/float loads get