Richard,
thanks for the answer, got it.
On 09/05/2018 07:51 PM, Richard Earnshaw (lists) wrote:
On 05/09/18 17:43, Denis Khalikov wrote:
Thanks for the answers.
I understood that, this hack makes more mess in codegen for arm,
but can you please clarify what did you mean by
Only a single regi
On 05/09/18 17:43, Denis Khalikov wrote:
> Thanks for the answers.
>
> I understood that, this hack makes more mess in codegen for arm,
> but can you please clarify what did you mean by
>
>>Only a single register can be used
>> as the frame chain.
>
> As far as I understood, GCC for arm with THU
Thanks for the answers.
I understood that, this hack makes more mess in codegen for arm,
but can you please clarify what did you mean by
>Only a single register can be used
> as the frame chain.
As far as I understood, GCC for arm with THUMB2 mode uses r7 register as
frame pointer register by d
Hi Denis,
>> Adding support for a frame chain would require an ABI change. It
> would have to
> > work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
> > effort.
> Clang already works that way.
No, that's incorrect like Richard pointed out. Only a single register can be
u
On 05/09/18 14:55, Denis Khalikov wrote:
> Hi Wilco,
> thanks for the answer.
>
>> Adding support for a frame chain would require an ABI change. It would
> have to
>> work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
>> effort.
>
> Clang already works that way.
> Please
Hi Wilco,
thanks for the answer.
> Adding support for a frame chain would require an ABI change. It
would have to
> work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
> effort.
Clang already works that way.
Please look at this commit:
http://llvm.org/viewvc/llvm-project/
Hi Wilco,
thanks for the answer.
> Adding support for a frame chain would require an ABI change. It
would have to
> work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of
> effort.
Clang already works that way.
Please look at this commit:
http://llvm.org/viewvc/llvm-project/
Hi Denis,
> We are working on applying Address/LeakSanitizer for the full Tizen OS
> distribution. It's about ~1000 packages, ASan/LSan runtime is installed
> to ld.so.preload. As we know ASan/LSan has interceptors for
> allocators/deallocators such as (malloc/realloc/calloc/free) and so on.
> O
Hi,
thanks for the answer.
> Switching on the frame pointer typically costs 1-2% performance, so
it's a bad
> idea to use it. However changing the frame pointer like in the
proposed patch
> will have a much larger cost - both in performance and codesize.
You'd be
> lucky if it is less than 10%
Hi,
> But we still have an issue with performance, when we are using default
> unwinder, which uses unwind tables. It could be up to 10 times faster to
> use frame based stack unwinder instead "default unwinder".
Switching on the frame pointer typically costs 1-2% performance, so it's a bad
idea
10 matches
Mail list logo
