[llvm-dev] [Sparc] vararg double issue on 32 bit Sparc processors

[Chris.Dewhurst via llvm-dev]

Hi,

I've discovered a problem on Sparc processors (specifically, LEON, but I suspect but can't verify that it also happens on all Sparc processors).

The problem is, or appears to be with using double values in Sparc (32 bit).

Specifically, double values are not being loaded into registers correctly within a function using va_args. Only half the value is loaded (i.e. 32, rather than 64 bits of the value).

What I have also found is that the failure does not happen in all circumstances. The simplest situation I've been able to re-create that avoids the problem is to put a store and subsequent load instruction around the va_arg instruction that deals with the double value. e.g. (in an .ll file):

This code fragment does not work:

  define void @foo(i32 %v, i8* %ap) local_unnamed_addr {
  entry:
    %ap.addr = alloca i8*, align 4
    store i8* %ap, i8** %ap.addr, align 4
    %0 = va_arg i8** %ap.addr, i64
    %conv = trunc i64 %0 to i32
    %1 = va_arg i8** %ap.addr, double
    ...

Whereas this nearly identical code fragment, wrapping the store and load around the "double" va_arg instruction does work:

  define void @foo(i32 %v, i8* %ap) local_unnamed_addr {
    entry:
    %ap.addr = alloca i8*, align 4
    store i8* %ap, i8** %ap.addr, align 4
    %0 = va_arg i8** %ap.addr, i64
    %conv = trunc i64 %0 to i32
    store i32 %conv, i32* @foo_arg, align 4
    %1 = va_arg i8** %ap.addr, double
    %2 = load i32, i32* @foo_arg, align 4
    ...

I had been attempting to make various changes to SparcISelLowering.cpp to try to simulate something similar where the code is output, but I don't feel as though I'm heading in the right direction. I'm still not sure quite where the source of the problem lies.

I can provide more details on specifics, but rather than head off into excessive details immediately, I'd appreciate if anyone can help me identify what direction I really should be taking to fix this problem. I'm not convinced I've been going about it the right way so far.

Chris Dewhurst, Lero, University of Limerick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/6e832839/attachment.html>