similar to: [LLVMdev] Is append in APFloat broken?

On Tue, Jul 24, 2012 at 3:06 AM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> wrote: > Hi @llvm, > > I stumbled over a strange behavior if a float containing a NaN is printed > (e.g. in the clang rewriter). The local template method "append" in > APFloat.cpp deduces the size from the char array, which for "NaN" is 4 > (including the trailing zero).

Am 24.07.2012 18:50, schrieb David Blaikie: > Do you have a test case to go along with this? Unfortunately not. It just popped up as a result of a programming error made by me. > The simpler fix seems to be to untemplate this code& have "append" > take a StringRef. We can just rely on the compiler to optimize away > the strlen in StringRef's (const char*) ctor as

Hi Hal, On Sun, Oct 2, 2016 at 7:43 PM Hal Finkel <hfinkel at anl.gov> wrote: > Hi Tim, > > How, in general, are you thinking about doing this? I ask because, as you > clearly know, the double-double format is formed by the sum of two > double-precision numbers, and the various arithmetic operations are formed > mostly in terms of double-precision arithmetic on the

APFloat is derived from C code using fixed width storage for the matntissa. When converting to C++ I changed it to variable- width storage for space efficiency and generality reasons. Unfortunately this leads to a complication during float->float conversions that I missed that isn't present when using fixed width storage. Dale - I think this solves the issue correctly whilst preserving

I have found some internal test failures due to the wrong constant folding on ppc_fp128. As documented in APFloat::PPCDoubleDouble, APFloat doesn't support PowerPC double-double correctly < https://github.com/llvm-mirror/llvm/blob/492acdd450bcdf9837494d6da029ed064f14fc33/lib/Support/APFloat.cpp#L74 >. To support this, we need to add a second tuple of (sign, exponent, significand) to

Sean, thanks for reminding this, Alp did commit a class derived from raw_svector_ostream conatining an internal SmallString he called small_string_ostream. The commit was reverted after a day due to a disagreement about the commit approval and apparently abandoned. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223393.html

The LLVM Tutorial, https://llvm.org/docs/tutorial/LangImpl01.html provides an excellent introduction to language definition and code generation. I am looking for a similar example that demonstrates how to use SmallString. Even a small test program, ———— #include <llvm/ADT/SmallString.h> int main(int argc, char **argv) { llvm::SmallString<32> str("hello world\n");

Here's a performance testcase for the raw_svector_ostream patch. On my WIndows x64 machine it runs in 1010ms with the current code and in 440ms with the patch applies. Is this OK to commit? 2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > Following a hint from Duncan in http://llvm.org/pr23395, here is a > revised patch. Rather then introduce the

+llvm-dev at lists.llvm.org The impact should be small as all the other streamers usually write directly to the memory buffer and only when out of buffer they call write(). OTOH, raw_svector_ostream (without a buffer) goes though write for every character or block it writes. It can work without virtual write() by overriding the existing virtual write_impl() but this is a slower code path for

I don't think we should make flush virtual. Why do you need to do it? Can't you set up the base class to write to use the tail of the memory region as the buffer? On 24 April 2015 at 06:46, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > Is this what you're thinking about? > The code is not tested yet, I'd like to know if the overall direction and >

I wanted to bring this up again. I still try to get access to the assembler of a jit-compiled function/module using llvm 3.8 and later. In 3.8 the interface to addPassesToEmitFile has changed and my old method doesn't work any more. In principle one gets the asm with targetMachine->addPassesToEmitFile( PM , *OS , llvm::TargetMachine::CGFT_AssemblyFile ) where *OS is a

Could you dig into why: + raw_ostream &write(unsigned char C) override { + grow(1); + *OutBufCur++ = C; + return *this; + } Is 3 times as fast as raw_svector_ostream? I don't see a good reason why that should be any faster than: raw_ostream &operator<<(char C) { if (OutBufCur >= OutBufEnd) return write(C); *OutBufCur++ = C; return *this; }

+update diff 2015-05-02 7:38 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > I outlined (is that the right > word?) raw_char_ostream::grow, raw_char_ostream::write (both) into > raw_ostream.cpp with less than 10% difference in performance. > > Profiling reveals that the real culprit is the code line > > OS.reserve(OS.size() + 64); > > called from

A very common code pattern in LLVM is SmallString<128> S; raw_svector_ostream OS(S); OS<< ... Use OS.str() While raw_svector_ostream is smart to share the text buffer itself, it's inefficient keeping two sets of pointers to the same buffer: In SmallString: void *BeginX, *EndX, *CapacityX In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur Moreover, at runtime the

On Sat, Jan 19, 2013 at 8:33 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > There isn't much use of std::string in LLVM because it's simply not > needed. There's very little string manipulation, so StringRef is often > a much better choice. When there is a need for string manipulation, > the strings are generally very short, so SmallString is better.

On Jul 9, 2010, at 12:59 PMPDT, Jochen Wilhelmy wrote: >>> I wonder why APFloat::convertToDouble asserts if it is not an >>> APFloat::IEEEdouble while the name "convertToDouble" suggests that >>> it >>> converts when it is not a double. >> >> The conversion is to (host) double, as the name implies. Among >> APFloat types, that is

On Dec 8, 2007, at 11:33 AM, Reid Spencer wrote: > Okay, but I imagine that leaves it still being used in APFloat.cpp > which > is also trying to be segregated to the support module. >> >> If this doesn't seem like a clean enough solution, there are other >> ways to potentially decouple APFloat more from the Serialization >> "library." The

Hi, I've been playing around with the APFloat class lately and I came across behavior I was not expecting based on reading the implementation comments and I'm wondering if it's a bug or intentional. The behavior concerns converting an APFloat to a string and back again. In the implementation of ``APFloat::toString(...)`` you can specify ``FormatPrecision`` as 0. The method comments

>> >> I wonder why APFloat::convertToDouble asserts if it is not an >> APFloat::IEEEdouble while the name "convertToDouble" suggests that it >> converts when it is not a double. > > The conversion is to (host) double, as the name implies. Among > APFloat types, that is only implemented for APFloat::IEEEdouble. > yes, it's to host double

Hi Ted, On Sat, 2007-12-08 at 06:59 -0800, Ted Kremenek wrote: > On Dec 8, 2007, at 1:13 AM, Reid Spencer wrote: > > > Hi, > > > > I'm trying to separate the Support, System, ADT and Config header > > files > > into the support module, per previous plans. However, APFloat.h is not > > self-contained: > > > > APFloat.h:105:43: error: