Page MenuHomePhabricator

Enable the _ExtInt extension on the BPF Target
Needs ReviewPublic

Authored by seanyoung on Dec 11 2020, 3:57 AM.

Details

Summary

I need to use _ExtInt on the BPF target. Simply switching it on seems to work fine.

I'm a not sure if anything else is needed. Please let me know if there is anything I can improve.

Diff Detail

Unit TestsFailed

TimeTest
16,230 msx64 debian > LLVM.Bindings/Go::go.test
Script: -- : 'RUN: at line 1'; /mnt/disks/ssd0/agent/llvm-project/build/bin/llvm-go go=/usr/bin/go test llvm.org/llvm/bindings/go/llvm
80 msx64 windows > LLVM.CodeGen/XCore::threads.ll
Script: -- : 'RUN: at line 1'; c:\ws\w1\llvm-project\premerge-checks\build\bin\llc.exe -march=xcore < C:\ws\w1\llvm-project\premerge-checks\llvm\test\CodeGen\XCore\threads.ll | c:\ws\w1\llvm-project\premerge-checks\build\bin\filecheck.exe C:\ws\w1\llvm-project\premerge-checks\llvm\test\CodeGen\XCore\threads.ll

Event Timeline

seanyoung requested review of this revision.Dec 11 2020, 3:57 AM
seanyoung created this revision.

From the CFE's perspective, this is all that should be needed. Is there a BPF code-owner who can test it and see if it is acceptable?

ast requested changes to this revision.Dec 15 2020, 5:19 PM

What's a use case?
The test is necessary.

This revision now requires changes to proceed.Dec 15 2020, 5:19 PM
seanyoung updated this revision to Diff 312172.Dec 16 2020, 4:11 AM

Add tests cases for _ExtInt on BPF. This makes the _ExtInt testing equivalent to the testing on every platform except x86-64.

The use-case is to use _ExtInt on BPF when targeting Solana BPF smart contracts. I am writing a solidity to BPF compiler which includes a standard library written in C. Solidity has types of 256 bits.

https://github.com/hyperledger-labs/solang/blob/master/stdlib/bigint.c#L378

We could enable ExtIntType in bpf backend. But we need some kernel changes related to BTF to accommodate the new types.
Currently, the kernel uapi file (linux/include/uapi/linux/btf.h) defines

#define BTF_INT_BITS(VAL)       ((VAL)  & 0x000000ff)

which means the maximum permitted number of bits for int type is 255.

Here, we try to define an int type 256 which will not fit in the BTF. Currently llvm can encode 256 in BTF as the last 4 bytes are available and llvm did not do strict checking.
But kernel will reject it. Based on available bits, the maximum allowed bits are

#define BTF_INT_BITS(VAL)       ((VAL)  & 0x0000ffff)

But I do not think we need that big range, maybe

#define BTF_INT_BITS(VAL)       ((VAL)  & 0x000003ff)

which encode up to 512 bit integer (for power-of-2)? Do you have an use case for even bigger number of int?

Anyway, in parallel to this llvm patch, you need to have kernel change to accept such ext int's, the following are main changes in kernel:

  • extend the above uapi to allow more bits in int type.
  • make sure btf pretty print can work properly with these big ints, it can handle __int128 (in both kernel and bpftool), you will need to extend to make it generic to handler 128/192/256/... bytes, I think.

Ok, I'll do that.