[PATCH][AArch64] Fix bug around passing VPR stack parameters

Tim Northover t.p.northover at gmail.com
Tue Jun 3 06:35:41 PDT 2014


> I don't want to block your progress of cleaning the conflict with generic
> parameter lowering code, so now I've committed my patch as r210067.
> You can just change whatever you want to merge with your new fix to
> solve that conflict with generic code.

Thanks.

> ValVT should be meaning the original type defined by end-user, while LocVT
> means the type we promote to following ABI, correct?

The terminology is confusing because AArch64 uses the fields in odd
ways. For other targets, ValVT is the "legal register type" that
generic code chooses (mostly i32 for small types), ArgVT is what the
user wrote (i1/i8/i16), and LocVT is what the TableGen .td files
decide (say, promote i32 to i64 when doing varargs functions).

For AArch64. ValVT is what the user wrote, LocVT is what it decides it
should be promoted to and Ins[i].VT is what the generic code decided
it wants. This mangling is done by the loop on line 1674.

> -      ArgValue = DAG.getExtLoad(ExtType, DL, VA.getValVT(), Chain, FIN,
> +      ArgValue = DAG.getExtLoad(ExtType, DL, VA.getLocVT(), Chain, FIN,
>                                  MachinePointerInfo::getFixedStack(FI),
> -                                VA.getLocVT(),
> +                                VA.getValVT(),
>                                  false, false, false, 0);
>
> Your code change of switching parameter passing of ValVT and LocVT got me
> confused.
>
> I think the memory load here should be from the pointer type of LocVT rather
> than ValVT, and the data we stored to register should be the type ValVT, and
> then the code inside the function should just use ValVT, right?

In most backends, it probably would be, but

> Instead, the the following fix in call site lowering looks good to me and it
> would keep the original type ValVT, and store it to LocVT pointer.

The fix you quoted later is in FastISel. Both need changing alongside
the .td file for good code.

Cheers.

Tim.



More information about the llvm-commits mailing list