- User Since
- Apr 11 2016, 3:46 AM (118 w, 6 d)
Fri, Jul 20
Thu, Jul 19
I removed the changes from D48222.
Comments from Simon and Roman were resolved.
Wed, Jul 18
I added required comments and did the required changes.
Tue, Jul 17
I replaced 'auto' with real types accordingly to Simon's request.
In fact we have there very similar issues but even with rr versions: we should separate implementations for different sizes 16/32/64. I'm going to complete it tomorrow. But again - most probably it will be w/o memory operands support like in D49243.
Now we use WriteRes instead of *WriteResPair.
Folded versions of the intrs will be implemented in the next patches.
http://www.agner.org/optimize/instruction_tables.pdf, page 202, "Intel Haswell", "List of instruction timings and μop breakdown" appears to list all the BT* as having latency of 1.
I mixed columns for latency and throughput: latency is missed.
Mon, Jul 16
I need your help!
It seems I fixed all issues raised by lebedev.ri. The open question is: should I remove the second check inside checkSchedClasses? I'm sure there is a way to get default values for such SchedWrites like WriteALU, WriteFAdd, etc. but I don't know at the moment how to do it. Please, help.
Fri, Jul 13
I renamed WriteBTr with WriteBitTest.
I could not add memory version of the instructions because there were some issues. For example, if we have
Thu, Jul 12
Now the patch keeps only infrastructure changes to produce new TableGen warns about sched models.
Wed, Jul 11
Tue, Jul 10
I fixed all issues raised by efriedma: GlobalDecl(FD), function body, class names, etc. Many tnx for your help.
Mon, Jul 9
I fixed warns for BSWAP instrs (see changes in X86*.td files). If this approach is OK I'll fix other instrs.
At the moment we have the following warns for X86:
In fact we have the warnings for 2 Targets only:
Tue, Jul 3
Now it's almost completed but should deal with deafult Latency value: hope to implement it soon. (The current version does not produce yet warning about identical uOps & Latency during compiler build: maybe it's OK?)
Hi! I was out for 2 weeks that's why I did not do anything here. Is it still interesting for you? I'm going to publish an update asap.
But the question is: how to get latnency/uop from CodeGenSchedClass ?
Jun 15 2018
Jun 7 2018
If I use one check only (" // Check if an instruction is always overriden (candidate for a new class?)") I see warnings for p9model only.
At the moment, I'm learning debug output related to generation of all these tables and hope to come up with some realistic logging soon.
Simon, I have some troubles with slack connection that's why I read your message only now :-( I'll back with answer asap.
Jun 6 2018
Of course not. First of all, I suggest to put AVX2 and AVX512 instructions in separate files and to use them in models which don't support AVX2 and/or AVX512. Etc.
Obviously, the idea was to use one include file for all targets. But it did not work in the first version of the patch. Now I did a "dirty hack" in TableGen to be able to do it. It works for 2 CPUs and obviously it should work for others. The usage is very simply: the common include file should keep the common unsupported instructions while the specific onces should be inserted into the specific .td files.
Jun 5 2018
And the last question. Again, in P9Model we have
Next, we have for P9Model only:
Something is wrong with current diagnostic. Fro example, we have
Jun 4 2018
To simplify the review I removed all LLVM_DEBUG items - now the patch is really shorter than it was before.
Jun 1 2018
May 30 2018
What should I do to simplify the review?
I could remove all LLVM_DEBUG related stuff; I could remove all addtional counters and leave only necessary one or two of them. As result the patch will become shorter.
May 24 2018
The sources were re-based to fit in LLVM_DEBUG rename.
One more counter was added.
Debug logging was improved again.
May 23 2018
- switched to llvm::sort - from std::sort (tnx to mgrang)
- added a new counter (hope it will improve the output numbers)
- slightly changed a couple of existing counters
- seriously improved debug/monitor logging
May 22 2018
Apr 24 2018
Apr 23 2018
Thank you very much! I'll try to fix it in this way.
It's terrible but my new test was failed again as result of commit of this patch!
Apr 20 2018
I fixed issues raised by efriedma.
Apr 19 2018
Are there other issues related to this patch?
If NO could anyone give me LGTM? I need this patch committed to continue with recursive time counters.
Apr 17 2018
I moved FrontendTiming.cpp from lib/Basic/ to lib/Frontend/.
Apr 16 2018
JFYI: the given patch introduces non-recursive (self-overlaps) timers only. I'm going to introduce self-overlaps timers when D45619 is committed.
Could you give me LGTM in this case? I'm going to publish "recursive"(ovelaped) timers but I'd like to base it on D45619.
Apr 14 2018
Apr 13 2018
Apr 12 2018
Apr 11 2018
Apr 10 2018
Obviously, this patch was not ready for commit that's why I reopen the revison.
But I don't know how to revert the patch from trunk: please, help me.
Could you help me with revert of the committed patch?
I'll do all necessary changes but I don't know how I can revert the patch.
Apr 9 2018
I fixed all issues raised by mzolotukhin and answered on his questions. I'm waiting for LGTM now.
It is not a bug.
The trunk fixed the issue.
Mar 30 2018
In fact I think about mul only because of X86 nature: it always put the mul result in wider place (than its args). (Don't know about other CPUs - maybe the same?) As result we could change the current design to reflect this feature:
Mar 29 2018
Mar 27 2018
If that operation overflows, so be it — we're not going to warn about the potential for overflow every time the user adds two ints, and by the same token, it doesn't make any sense to warn about every time the user adds two shorts just because the language made this otherwise-unimportant technical decision to do the arithmetic in a wider type.
Mar 26 2018
Mar 22 2018
I re-based sources to reflect commit of D43813.
That's an interesting question. In general, these warnings do try to ignore the effects of implicit promotion. We would not want -Wsign-conversion to fire on unsigned short x = an_unsigned_short + 1; (or - 1, for that matter), even though formally this coerces a signed int to unsigned short. Similarly, -Wsign-conversion *should* warn on signed short x = an_unsigned_short + 1;, even though formally the promotion from unsigned short to signed int is not problematic and the final conversion from signed int to signed short is not a signedness change. (This second example should also generate a -Wconversion warning, but the questions are independent.) Applying that strictly here would say that the user is entitled to think of this as an operation on unsigned char that then gets losslessly promoted to signed short, even though arithmetically that's not what happens. On the other hand, I do think there's some room for -Wsign-conversion to be more aggressive than -Wconversion about this sort of thing; -Wsign-conversion should generally fire for any changes in signedness from the original operand types (with the usual complexities around constant values), and there's just an exception for computations whose value is known to fit within the expressible range of the result type, which is not true of this multiplication. So I think it would be acceptable to warn on this.
Mar 21 2018
I removed the dependence on arch and updated the tests.
Could you please clarify, are you saying that PR35409 is not a bug, and clang should continue to not warn in those cases?
Mar 16 2018
It's committed: https://reviews.llvm.org/rC327618.