Displaying 7 results from an estimated 7 matches for "uinstead".
Did you mean:
instead
2019 Jun 30
2
Information Loss of Array Type in Function Interface in IR Generated by Clang
...g
Subject: Re: [llvm-dev] Information Loss of Array Type in Function Interface in IR Generated by Clang
LLVM IR doesn't maintain a lot of information present in the source. What were you hoping to do with that information? Perhaps you'd be best off doing something up in clang/using the AST uinstead of LLVM IR?
On Sat, Jun 29, 2019 at 10:36 PM Tingyuan LIANG via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Dear all,
Hi! Recently, I notice a situation where I cannot infer the size of the outermost dimension of array in the function interface....
2019 Jun 30
2
Information Loss of Array Type in Function Interface in IR Generated by Clang
Dear all,
Hi! Recently, I notice a situation where I cannot infer the size of the outermost dimension of array in the function interface.
To concretely depict the problem, I show the C source code and the generated IR code at the end. The array size of A[] is 51 but this information is lost in the generated IR.
How can I maintain such information in IR? Should I set some argument for
2020 May 29
2
Range lists, zero-length functions, linker gc
...;
> > each section takes 64 bytes in the section header table.
Soryr, I missed a step here - you're talking about the cost to
fragmenting .debug_* sections as an alternative to choosing a special
address value to resolve for dead code? (by removing the DWARF that
refers to the dead code, uinstead of keeping it and having to write a
special address value into it?)
Unfortunately, no matter the cost - that solution doesn't apply to
Split DWARF. Maybe at some point we'll want to have some output from
the linker that lists the dead/live code, and use that for building a
dwp (like dsymut...
2020 May 29
2
Range lists, zero-length functions, linker gc
...ction header table.
> >
> > Soryr, I missed a step here - you're talking about the cost to
> > fragmenting .debug_* sections as an alternative to choosing a special
> > address value to resolve for dead code? (by removing the DWARF that
> > refers to the dead code, uinstead of keeping it and having to write a
> > special address value into it?)
> >
> > Unfortunately, no matter the cost - that solution doesn't apply to
> > Split DWARF. Maybe at some point we'll want to have some output from
> > the linker that lists the dead/live c...
2020 May 31
2
Range lists, zero-length functions, linker gc
...gt;> > Soryr, I missed a step here - you're talking about the cost to
> >> > fragmenting .debug_* sections as an alternative to choosing a special
> >> > address value to resolve for dead code? (by removing the DWARF that
> >> > refers to the dead code, uinstead of keeping it and having to write a
> >> > special address value into it?)
> >> >
> >> > Unfortunately, no matter the cost - that solution doesn't apply to
> >> > Split DWARF. Maybe at some point we'll want to have some output from
> >&g...
2020 May 31
3
Range lists, zero-length functions, linker gc
...d a step here - you're talking about the cost to
> >> >> > fragmenting .debug_* sections as an alternative to choosing a special
> >> >> > address value to resolve for dead code? (by removing the DWARF that
> >> >> > refers to the dead code, uinstead of keeping it and having to write a
> >> >> > special address value into it?)
> >> >> >
> >> >> > Unfortunately, no matter the cost - that solution doesn't apply to
> >> >> > Split DWARF. Maybe at some point we'll want...
2020 May 29
4
Range lists, zero-length functions, linker gc
On 2020-05-28, David Blaikie wrote:
>On Thu, May 28, 2020 at 2:52 PM Robinson, Paul <paul.robinson at sony.com>
>wrote:
>
>> As has been mentioned elsewhere, Sony generally fixes up references from
>> debug info to stripped functions (of any length) using -1, because that’s a
>> less-likely-to-be-real address than 0x0 or 0x1. (0x0 is a typical base
>>