== Progress ==
* GCC:
- -mpure-code on v6m: sent an updated patch, waiting for approval.
* BFD Linker:
- non-contiguous memory support: partial prototype working on the
use-case, but causes regressions.
* GCC upstream validation:
- reported several issues
* misc:
- infra fixes / troubleshooting
QEMU Tooling ([VIRT-252])
=
Extend gdbstub for SVE ([VIRT-281])
- worked on [v2 rebase addressing comments]
[VIRT-281] https://projects.linaro.org/browse/VIRT-281
[v2 rebase addressing comments]
https://github.com/stsquad/qemu/tree/gdbstub/sve-registers-v2
Upstream
[Morello]
- LLD finished pre-review refactoring and splitting up into reviewable chunks
- Implemented range-extension and interworking thunks to test
interaction with aligning .text to comply with Cheri Concentrate
- Answered some questions from Linaro tech-leads about Morello
Plans
- Rebase once
I should say that you need all three options to prevent the code motion from
happening:
-fno-tree-loop-im -fno-tree-pre -fno-gcse
-fno-tree-ch prevents the code motion from happening too but only on accident;
in that all three of the code motion passes (the two on the gimple and one on
RTL) won
>Thanks for the information, at least for the specific snippet it seems that
> both -fno-tree-loop-im and -fno-tree-pre are the ones generating most
> spilling.
That is because the code motion is happening at the RTL level: -fno-gcse is the
one you are looking for.
__
On 22/11/2019 11:38, Andrew Pinski wrote:
>> It is enabled in all optimization levels besides -Os (since besides possible
>> increasing the stack usage it also might increase code side).
> It is disabled at -Os because it is duplicating the loop header; which in
> turn is considered increasing c
>It is enabled in all optimization levels besides -Os (since besides possible
> increasing the stack usage it also might increase code side).
It is disabled at -Os because it is duplicating the loop header; which in turn
is considered increasing code size (though sometimes that can have a side
ef
Actually note it is not -ftree-ch which is causing the problem but rather
-ftree-ch allows for other optimizations due their work. E.g. I need to turn
off all of loop invariant code motion to get rid of the spilling:
"-fno-tree-loop-im -fno-tree-pre -fno-move-loop-invariants -fno-gcse".
Also
On Fri, Nov 22, 2019 at 2:40 PM Adhemerval Zanella
wrote:
>
> Hi Arnd,
>
> I took a look on the stack usage issue in the kernel snippet you provided [1],
> and as you have noted the most impact indeed come from -ftree-ch optimization.
> It is enabled in all optimization levels besides -Os (since b
Progress:
* VIRT-65 [QEMU upstream maintainership]
- code review:
+ Marc-Andre's series trying to get rid of QOM pointer properties
+ various minor bits for rc2
- unsuccessfully tried to work out why one of QEMU's test
cases asserts on BSD hosts only
- some time consumed by office-
On 22/11/2019 10:55, Arnd Bergmann wrote:
> On Fri, Nov 22, 2019 at 2:40 PM Adhemerval Zanella
> wrote:
>>
>> Hi Arnd,
>>
>> I took a look on the stack usage issue in the kernel snippet you provided
>> [1],
>> and as you have noted the most impact indeed come from -ftree-ch
>> optimization.
>>
Hi Arnd,
I took a look on the stack usage issue in the kernel snippet you provided [1],
and as you have noted the most impact indeed come from -ftree-ch optimization.
It is enabled in all optimization levels besides -Os (since besides possible
increasing the stack usage it also might increase cod
== Progress ==
* Triaging check-lldb failures on AArch64 [LLVM-512]
- Opened 4 bug reports
- One of them got a lot of attention so I was asked to upload more
logs/try various things
- Still have a couple of test failures to look into
* Morello
- First contact with the team
- Started loo
13 matches
Mail list logo
