- User Since
- Nov 16 2012, 6:02 PM (339 w, 3 d)
Thu, May 16
Wed, May 15
Tue, May 14
It might be simpler to describe the semantics in terms of GEP: e.g. ptrmask(x) is equivalent to gep x, (ptrtoint(x)&mask)-ptrtoint(x). I think that has the same semantics as the description, but it might be easier to understand for a reader familiar with GEPs.
I don't see why but I might be wrong (@hfinkel). What I thought is detailed below.
We should watch for perf regressions on x86, and other targets.
Mon, May 13
If this test case proves too fragile in the future, we might replace it with an MIR test.
Fri, May 10
Thu, May 9
Wed, May 8
Tue, May 7
Is this really a target-independent problem?
Mon, May 6
Sat, May 4
Seems reasonable to me. Can have have both a 128- and 256-bit test case?
Fri, May 3
It is up to you. I don't have strong objections if you think this will work as required. Just the tests must be fixed, especially codegen tests.
Still, I think we need to prvide the default implementation of those non-standard functions (they can be very simple, maybe reporting error is going to be enough), which can be overriden by user.
Thu, May 2
Only if they also differ in some other way. C++ does not (generally) have return-type-based overloading. The two functions described would even mangle the same way if CUDA didn't include host/device in the mangling.
Wed, May 1
Does the code that uses __kmp_load_mxcsr expect the pointed-to value to be initialized?
Tue, Apr 30
Mon, Apr 29
While I'm sympathetic, we have a lot of benchmark names which are short and could conflict with other things. We have xsbench too. Either we should solve this uniformly, or not at all. You can always carry local patches for name conflicts with out-of-tree things.
For some special cases, the performance can improve more than 30% after adding the patch for ppc.
Thu, Apr 25
Wed, Apr 24
Why don't we always do this? Isn't assuming that the register is always read the conservatively-correct thing to do here?
Apr 19 2019
Apr 18 2019
Pending instructions that may have been blocked from being available by the HazardRecognizer may no longer may not be blocked any more when an instruction is scheduled; pending instructions should be re-checked in this case.
Apr 17 2019
Can you please take the rationale, especially for LoopSimplify, and add it as a comment in the source code? At some point someone might break this invariant, and without the comment, they'll be no easy way to know that.
How will this appear to profiling tools using PC sampling and using debug info to map the PC samples back to line numbers in the code?
Apr 16 2019
In the new pass manager, getting access to BPI reliability is a challenge. In practice, we've been running downstream with a variation of this non-BPI based heuristic.
Is this still useful for debugging problems with MemSSA and GVNHoist? Is this mirrored in the new pass manager?
Do we need to adjust the new pass manager too?
Apr 15 2019
Apr 14 2019
Apr 13 2019
Apr 12 2019
Why don't we have unit tests here or in the llvm-test suite?
Because this is the library. Do you have an idea how to write the unit tests for it? It can be tested only with the executable tests.
We write google unit tests for various components, maybe something like that works here as well. A test that makes sure the initial output of omp_get_level is now 1 would then be great. It is by far not trivial to determine that omp_get_level, if called with an uninitialized device RT, should return parallelLevel + 1.
I know, that someone worked on the target-based testsuite, but don't know when it is going to be ready.
There is the V&V test suite: https://crpl.cis.udel.edu/ompvvsollve/
We could also add openmp target tests into the LLVM Test Suite and run them if people define CMAKE flags.
Actually, it was the testsuite, which reveals the problems with the runtime. But only after some changes in the compiler I made to run more constructs in SPMD. Before that they all were executed in non-SPMD and the problem was masked. And I don't see a problem here since the exhaustive testing is impossible in principle.
If you have a testsuite and ready to prepare and send an RFC, solve the problems with the license, organize it, setup buildbots, provide support, then go ahead. We can do everything, but it requires a lot of time. I agree that we need target-specific testing.
Apr 11 2019
Apr 9 2019
Apr 8 2019
Apr 7 2019
Because SCEV doesn't have access to AA,
Apr 5 2019
Apr 4 2019
Looks like this needs to be updated with the new license headers.
Apr 3 2019
Is this transparent to tools that use LLVM's YAML library? Other tools?
I would question whether it's actually worth it to attempt to keep software working that seems to have been abandoned for a decade as part of the llvm test suite? Should this code just be removed, instead of patched?
Mar 29 2019
I am also not entirely sure how control dependencies could add new underlying objects with this patch
Mar 21 2019
The audience of this are people who are defining new target intrinsics.
I don't understand what this is supposed to mean to who the audience of this statement is?
Mar 20 2019
Mar 19 2019
We need to make progress on this, and I'd like to suggest a path forward...
Mar 15 2019
LGTM. Maybe we can also add the test case from the PR as one of Clang's regression tests?
Mar 14 2019
I'm really afraid that this isn't sound. We've had a number of issues in this space, and we've always resisted attempts to make BasicAA look through inttoptr/ptrtotint. Once you convert to an integer, control dependencies can effectively add additional underlying objects. In cases where this is sound, why not fold away the whole inttoptr(and(ptrtoint)) in the first place?