[Mesa-dev] Error: unsupported relocations
Dave Airlie
airlied at gmail.com
Mon Jun 3 07:43:21 UTC 2019
On Mon, 3 Jun 2019 at 11:37, Jan Vesely <jan.vesely at rutgers.edu> wrote:
>
> On Mon, 2019-06-03 at 11:12 +1000, Dave Airlie wrote:
> > On Mon, 3 Jun 2019 at 10:58, Jan Vesely <jan.vesely at rutgers.edu> wrote:
> > > On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote:
> > > > I've started a thread on the llvm mailing list. See
> > > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2F2019-June%2F132750.html&data=02%7C01%7Cjan.vesely%40cs.rutgers.edu%7Ce7c33507211c4512c6ad08d6e7c09d49%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636951211793224808&sdata=lyayMkDxUbTCye%2BynlBZ8sp%2Fc4u5kS4pv%2B2MMeSegoM%3D&reserved=0
> > > >
> > > > I don't know if it's needed, but if anyone has a commit in llvm that
> > > > started this, that might be helpful.
> > >
> > > thanks. however most LLVM developers contributing to AMDGPU backend
> > > are AMD folks. The ROCm based stack can handle relocations, so it's up
> > > to a volunteer to step up and post a patch (either for mesa or llvm).
> > > Fewer relocations should mean faster dispatch, so you they should be
> > > interested in taking the LLVM fix.
> > >
> > > I've started looking, but the elf structure lists relocations against
> > > a section (STT_SECTION), so I still don't know where to get target
> > > address.
> >
> > Jan,
> >
> > this is clearly inline not working, not relocs. We never get the
> > missing function to relocate it.
>
> The imagemagick issue might be missed inlining.
> I'm working on call* piglits, which mark functions as 'noinline' to
> force function calls.
> the code clearly expects relative function address:
> s_getpc_b64 s[8:9]
> s_add_u32 s8, s8, i64_func_void at rel32@lo+4
> s_addc_u32 s9, s9, i64_func_void at rel32@hi+4
> s_mov_b32 s32, s10
> s_swappc_b64 s[30:31], s[8:9]
> Inspecting the asm and symbol table, the callee functions are there.
> It might be that relocations issued for amdgcn-mesa-mesa3d triple are
> busted, I'd expect it to use single 4B relative pointer, but last time
> I talked to Matt he said it looked correct.
Okay so this doesn't appear to be that.
commit 5d567dc137d20a9d9654076fbdab8ceddb6748dc (HEAD, refs/bisect/new)
Author: Matt Arsenault <Matthew.Arsenault at amd.com>
Date: Thu Feb 28 00:40:32 2019 +0000
AMDGPU: Enable function calls by default
LLVM 8 release fails to inline some functions, this commit in llvm 9
fixes that for some reason.
Which is totally the opposite of what i'd expect here.
Dave.
More information about the mesa-dev
mailing list