User Details
- User Since
- Mar 13 2015, 4:38 PM (445 w, 8 h)
Thu, Sep 21
This looks good with just one nit above.
Wed, Sep 20
This is good too. Thanks!!!
Are
Tue, Sep 19
this looks good
Fri, Sep 15
This look good
This is LGTM as you suggested pending child reviews.
This looks fine just couple of nits inline.
This is LGTM. Thanks for your patience.
Thu, Sep 14
This apparently requires a rebase now.
Wed, Sep 13
Why do we have svg and za in different register sets?
This looks good overall thanks for doing the patch split makes the review way less overwhelming.
Tue, Sep 12
In this test can we figure out whether SVE was read from Streaming mode or normal SVE mode?? and if yes may be add a check for that.
This patch requires rebasing does not apply cleanly on top of its parent.
Can you add more description to this patch. at the moment reading it without SME context in mind does not provide enough information to figure out what we are doing.
The patch looks to implement all stuff needed at once lets break it down into three patches instead:
- First patch that just adds SME register set and does not implement RegisterContext Read/Write routines.
- Implement register context read/write for SME registers
- Implement size re-configuration after changing size of the SME vector.
Sun, Sep 10
Wed, Sep 6
Mon, Sep 4
Fri, Sep 1
Thanks!
Thu, Aug 31
Tue, Aug 29
I don't know about expensive literally but I did wonder if we could rely on the NativeRegisterContextLinux_arm64 buffers not being modified while the expression runs. Then do what I think you mean which is just flush them all to the process.
I'll need to work out exactly when SaveAll/WriteAll is and can be called. Part of me wonders why we even have such methods if you could just flush the existing buffers, but it wouldn't be the first time we've duplicated things.
I have a feeling that expressions are becoming an expensive operation with amount of data we need to move back and forth between various buffers. Is there a way we can optimise this may be write register directly from source buffer.
Also how much minimum data we need to move when SME is enabled?
This looks fine but instead of adding a new test cant we add MTE control register tests to already available MTE tests?
Mon, Aug 28
Aug 7 2023
Never mind got the answer from the summary.
Thanks David for adding this builder. Re debug builder do you plan to remove the flang-aarch64-debug after the new builder is up and running. I guess if we add a new builder with DLLVM_REVERSE_ITERATION=ON we ll loose the ccache advantage given many files will get built twice for the same set of changes.
Aug 3 2023
This looks good. Just a nit the summary seems to be using a lot pronouns. Could you kindly improve summary a little and add a one liner about expr_func and how it tests save/restore for future readers of this log.
Looks legit. Thanks
@farzon thanks for this fix. Please upload a full context diff using
git diff -U999999 --no-color HEAD^
Jul 27 2023
Jul 21 2023
I guess there is not much gain from telling the user between sve/ssve mode for the moment. Can we defer this patch till SME registers are implemented?
This looks very good much simpler from the first version. just a minor nit.
This looks good just a minor suggestion inline.
Jul 19 2023
This update fixes some bugs after testing.
Jul 16 2023
Jul 14 2023
Sounds ok to me. We can always fix it if starts to cause trouble.
Jul 4 2023
Jul 3 2023
Jun 27 2023
This seems to have broken https://lab.llvm.org/buildbot/#/builders/245/builds/10311
Jun 19 2023
Jun 15 2023
This looks good to me, just a minor nit above. I have not run the test myself.
Jun 14 2023
This looks good.
May 30 2023
May 29 2023
Kindly fix flang unit tests for Windows before relanding. Thanks
This change has broken various unit tests on AArch64 Windows platform. I going to revert this change temporarily.
May 22 2023
May 16 2023
Hi Aaron,
May 15 2023
This caused test failure on lldb-aarch64-windows buildbot
https://lab.llvm.org/buildbot/#/builders/219/builds/2520
This introduced test failures on windows lldb-aarch64-windows buildbot.
May 2 2023
Apr 26 2023
Apr 19 2023
HI Manoj
Which linux distro are you using for your cross build? I am wondering which version of gcc (aarch64-linux-gnu) are you using for your cross compilation build.
I believe sve headers are not defined in older versions of gcc or its packaged sysroot causing cross compilation build to break.
All sve:: functions and defines are just a make shift arrangement to accommodate build environment which dont have SVE headers/functions defined.