|
From: Julian S. <js...@ac...> - 2013-07-10 11:41:37
|
Hi s390ers and mipsers, I've been working on a comprehensive fix for https://bugs.kde.org/show_bug.cgi?id=294285 (deal properly with partially-valid 128- and 256-bit vector loads). The core of the problem is that the calls to dirty helper functions that Memcheck generates need to be able to return 16-byte values, and probably in the future 32 byte values. To do this I added the ability of helper functions to return a V128 or V256 by reference. The helper function can declare a V128*/V256* parameter, which it is assumed to put the result in. At the IR level the position of the out parameter is marked by a special value in the argument list (IRExprP__VECRET), but apart from that there's no change at the IR level. The back ends have to be modified to allocate space on the stack when they see such a value, pass the address to the callee, and read the value back out after the call. Passing of the baseblock pointer is now done similarly (IRExprP__BBPTR) and IRDirty.needsBBP is gone. This scheme is probably lower performance than using ABI-specific struct-return conventions, since it goes via memory, but it's simpler and avoids exposure to potential struct-return bugs in gcc -- since it requires no cooperation at all from gcc. Also, in the big picture, this allows replacing two calls to MC_(helperc_LOADV64) with a single call to MC_(helperc_LOADV128) so that should more than compensate for passing the value through memory. Anyway: I have modified the amd64, x86 and ARM back ends to deal with this, and I will do the ppc32 and ppc64 back ends later this week. I could probably do the mips32/64 cases if I could find a working gcc-compile-farm MIPS machine, which I can't. But I can't do the s390 back end. So .. can I enlist your help with this? Because (AFAIK) neither the s390 nor mips back ends deal with vectors, this should be pretty straightforward. It is essentially a change to how doHelperCall in host_xxx_isel.c is called. No change in the generated code. Thanks, J |
|
From: Petar J. <mip...@gm...> - 2013-07-11 00:02:31
|
On Wed, Jul 10, 2013 at 1:42 PM, Julian Seward <js...@ac...> wrote: > > Anyway: I have modified the amd64, x86 and ARM back ends to deal > with this, and I will do the ppc32 and ppc64 back ends later this > week. I could probably do the mips32/64 cases if I could find a > working gcc-compile-farm MIPS machine, which I can't. But I can't gcc49 has not been working for a few days now. I have just open a ticket at http://gna.org/bugs/?20961 hopefully, it will be back again. As of MIPS part, as discussed elsewhere, you do not have to worry about it, when you have the patch ready share it (or commit it), and we will take care of it immediately. Thanks for the heads up. Petar |
|
From: Maran P. <ma...@li...> - 2013-07-11 06:13:18
|
On 07/10/2013 05:12 PM, Julian Seward wrote: > Anyway: I have modified the amd64, x86 and ARM back ends to deal > with this, and I will do the ppc32 and ppc64 back ends later this > week. I could probably do the mips32/64 cases if I could find a > working gcc-compile-farm MIPS machine, which I can't. But I can't > do the s390 back end. > I will be able to address the changes required for the s390 back end. Please share the patch. Thanks. -- Maran |
|
From: Julian S. <js...@ac...> - 2013-08-01 16:39:19
|
Hi Maran, Petar, On 07/11/2013 08:12 AM, Maran Pakkirisamy wrote: > On 07/10/2013 05:12 PM, Julian Seward wrote: >> Anyway: I have modified the amd64, x86 and ARM back ends to deal >> with this, and I will do the ppc32 and ppc64 back ends later this >> week. I could probably do the mips32/64 cases if I could find a >> working gcc-compile-farm MIPS machine, which I can't. But I can't >> do the s390 back end. >> > I will be able to address the changes required for the s390 back end. > Please share the patch. Thanks. Done. There are vex and valgrind patches at https://bugs.kde.org/show_bug.cgi?id=294285 comments 9 and 10. You'll need to apply both. I have done as much as I can with them -- the x86, amd64, arm, ppc32 and ppc64 front/back ends work. s390, mips32, mips64 won't compile. To hack on this, you'll first need to re-add priv/guest_<arch>_toIR.c and priv/host_<arch>_isel.c to LIBVEX_SOURCES_COMMON in Makefile.vex.am, and you'll also need to remove the #if 0's around the relevant sections in LibVEX_Translate in VEX/priv/main_main.c. The real changes are restricted to the _toIR.c (a bit) and the _isel.c (mostly). For both MIPS and S390 I think it is pretty simple because there is (IIUC) no SIMD code generation. So the changes needed are: * in _toIR.c: any place where a dirty helper call is created, and you want to pass the baseblock pointer: - remove d->passBBP = True (since that field no long exists) - add the special value IRExprP__BBPTR as the first arg in the arg list for the call. This tells the backend to pass the baseblock pointer as the first arg * in _isel.c: - doHelperCall needs to be modified to handle IRExprP__BBPTR in arg lists - doHelperCall does not need to handle IRExprP__VECRET since we're not expecting to handle 128 or 256 bit returns on these architectures - doHelperCall needs to be modified to create and return the RetLoc value for the call; previously this was passed in to doHelperCall - see doHelperCall in host_isel_ppc.c for examples/ideas/code to copy - I suggest you add "vassert(0) // ATC" initially in all the various IRType-differentiated switches, so as to be sure all paths are verified. - I tested by running all the insn set test for each arch on Memcheck. Testing with --tool=none isn't enough since Memcheck creates calls with arg/return types that don't exist in the uninstrumented IR. Any questions, please ask. I will do the integration/committing, since that can't happen until all targets are working again. J |