[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 214950] New tool exp-floattrap
From:       Mathias Fröhlich <Mathias.Froehlich () gmx ! net>
Date:       2015-08-01 13:54:23
Message-ID: bug-214950-17878-bfLsCP8otX () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=214950

--- Comment #8 from Mathias Fröhlich <Mathias.Froehlich@gmx.net> ---
Hi Florian,

On Saturday, August 01, 2015 10:32:56 Florian Krohm wrote:
> > When I see c++ comments, I would think that valgrind wants c comments, right?
> > 
> 
> For multi-line comments we'd like C-style. For inline comments C++ comments are
> fine, but there is no strong preference one way or the other.
Ok, so, I will adapt the longer ones at least.

> > > +insert_check_double128(IRSB* bb, IRTemp value)
> > > +{
> > > +  IRTemp tempHi, tempLo;
> > > +
> > > +  tempHi = addUnop(bb, Ity_F64, Iop_F128HItoF64, IRExpr_RdTmp(value));
> > > +  insert_check_double(bb, tempHi);
> > > +
> > > +  tempLo = addUnop(bb, Ity_F64, Iop_F128LOtoF64, IRExpr_RdTmp(value));
> > > +  insert_check_double(bb, tempLo);
> > > 
> > > So you're using insert_check_double twice. I doubt that is correct.
> > Twice, yes, once on the high and once on the low part.
> > Actually, that is something I was wondering about. I was looking for a
> > conversion
> > operator from F128 to I128 so that I can do the same bitmask trick like the
> > others precisions do. But I could not find such a conversion.
> > So how is that F128 supposed to work with VEX? Is this the usual doubledouble
> > approach or is this a real 128 bit IEEE float?
> 
> F128 is a true 128 bit IEEE float. You cannot look at it as two 64 bit floats.
> There is no need for a F128 to I128 conversion because there are no 128 bit
> wide integers on the platforms we support. You can convert to I64 or I32 or
> take the low and high 8 bytes of an F128.
> I have access to a machine with 128 bit floating point values to I can help
> with testing that.
Ok, I will provide something that that should work in theory - if you can care
for the practice it would be great!!!

> > Is there some more documentation on VEX? I just did match what appears
> > plausible to me.
> 
> libvex_ir.h is the main documentation and the lackey source tree (and 'none'
> source tree) are good for inspiration.
Ok.

> > So, having said that, if there is a chance for this to go upstream, I can
> > polish whatever
> > you want. But if not, I have to realize that there is life beyond software
> > which I enjoy also.
> 
> This is the main point we need to discuss before I take another look at the
> patch.
> The tool itself is simple enough so, once finalised, I do not see much of a
> maintenance issue. We can just carry it along and adjust to VEX changes of
> which there are not many.
> 
> However, having a proper set of testcases is critical to getting the patch
> upstream. What is currently there is not good enough. Also, you need to
> convince us that the code is working properly. It currently does not for 128
> bit floats and I'm not at all sure that the handling of the
> various SIMD IROps is correct either. Testcases help here as well as do more
> comments in the code.
> You need to figure out for yourself whether that is something you're willing to
> do.

Under these conditions, I am fine!
I can provide test cases and complete the missing stuff!
And I am around for questions at any time. My mail address did not change for
the
at least 15 years, so you can really reach me and I am willing to help also
past any initial contribution.

In the initial mail regarding this tool some years ago one of the valgrind
people
was talking about maintainership for this thing. And this is just one notch too
strong for me. If I personally say that I will maintain this in the future,
than
I commit myself to constantly monitor the valgrind development mailing lists
and
respond in time to requests coming in there. At least this is what I would mean
when I ask somebody for maintainership. But I cannot take maintainership in the
sense I understand mainteinership for each of the about 1000loc contributions
that I did in the past for OSS projects. And yes, as you said, the tool is
small
and not that hard to understand.

If we are really talking about upstreaming, there is no need to convince me
that
test cases are important and that it should work in all cases. I just won't
spend my
spare time polishing if we end up later with this maintainership discussion
again.

So, from what I can hear, expect a full set of test cases coming up soon.

Greetings from Stuttgart/Germany

Mathias

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]