- User Since
- Mar 27 2015, 6:20 AM (204 w, 1 d)
Fri, Jan 25
Thu, Jan 24
Jan 22 2019
Added BNF grammer for !cond as suggested .
Jan 16 2019
I have made the changes as requested. That is, removed explicit 'default' while sticking to overall syntax as before. I found that removing default in fact simplifies the implementation somewhat. Also, have split the tests to cleaner separate ones.
Jan 3 2019
I have changed the syntax from !ifs to '!cond' now, while retaining the others parts from original !ifs (instead of from LISP). Please let me know if changes are ok with you.
Dec 24 2018
Changes based on review comments. The new operator is now called '!cond', and 'default' must be the last clause.
Dec 21 2018
LGTM but will wait for a while to allow others comment as well, if necessary.
Dec 19 2018
Dec 18 2018
Dec 17 2018
Dec 10 2018
Nov 9 2018
Nov 6 2018
Oct 30 2018
Oct 29 2018
Could you add assembler/disassembler tests for udf ?
Oct 16 2018
Oct 12 2018
Oct 10 2018
Oct 2 2018
Oct 1 2018
Sep 26 2018
Looks like you forgot to add context (git diff -U9999)
Sep 19 2018
Sep 11 2018
Aug 29 2018
Would it be possible to add a test case that highlights the problem you are solving e.g. take a processor that has multiple resources (e.g. two adders) and show that it now can use both resources in same cycle.
Aug 9 2018
Jul 25 2018
Maybe you can provide some more context to this patch (why you need this, or point to some document), if possible.
Jul 23 2018
Yes Jonas it is purely cosmetic. Sometimes maybe be useful for code maintenance to show that certain records/values are not-possible
Jul 18 2018
Jul 13 2018
Jul 2 2018
Is this applicable only for ARMv6 case? From the patch it does not seem so and so may be good to add cases for ARMv7 as well.
Jun 29 2018
Jun 28 2018
Jun 14 2018
Jun 13 2018
LGTM but will wait for others to comment as well before accepting
Jun 11 2018
Probably good to mention that this patch relies on https://reviews.llvm.org/D48013
Its not clear to me why 'GenericTable' is more efficient/better than SearchableTable. Maybe you could give some background in the commit message about this. I implemented the ARMSystemRegister bit sometime ago and found SearchableTable quite useful and concise but perhaps GenericTable/Enum is even better.
Jun 7 2018
but did not find a way to do this (I think that it didn't work to express a LSU#I SchedWrite). I guess the current above will have to do?
This will work.
Jun 6 2018
Jun 5 2018
Jun 4 2018
May 31 2018
May 30 2018
Should the commit message be " Splat floating-point immediate value to SVE vector". Or may be i am wrong on this?
May 29 2018
May 24 2018
May 23 2018
I am not an expert in encryption but how likely it is for 'key' to be zero ?
Other than that, LGTM
May 20 2018
May 17 2018
May 15 2018
LGTM but then I wrote it originally so better to wait for comments from others.
May 14 2018
Suggestion for commit message - "Add support and tests for contiguous Prefetch instructions different variants."
The problem i find sometimes with long title is that it it truncated.
May 13 2018
May 12 2018
May 11 2018
May 10 2018
Having discussed with Sander and Florian in detail I now agree it is better to add properly grouped Scheds later.
I would then suggest adding the following to AArch64Schedule.td and then simply assigning the appropriate Scheds.
Much less work and neater doing it now when the instruction implementation is being done.
I might be good to put commit-message/description.
May 9 2018
May 3 2018
Does FDIV use both the resources for 8 cycles? Writing [8,8] would imply that.
May 2 2018
Ah! OK, I see. Thanks for the clarification.
Thanks for this check.
If ResourceCycles is not specified then it should default to 1 . I believe most people write with that interpretation.
If ResourceCycles is specified for at least one resource, it makes sense from correctness POV that it be specified for all (even though it might get verbose at time).
May 1 2018
Hi Kristof. Thanks for this.
Apr 30 2018
Apr 27 2018
Please rephrase this part of commit message as it is hard to read/understand - "And even if statistics is disable and code
related to it will be eliminated the invocation to getExact itself will not be eliminated because it may have side-effects like creation of new SCEVs".
AFAIU the correctness check would now get gated on STATS colelction and that may not be right. I would recommend separating the two.