[polly] r248603 - Use per-Purpose overloads for MemoryAccess creation

[Johannes Doerfert via llvm-commits]

> 2015-09-26 18:43 GMT+02:00 Johannes Doerfert <doerfert at cs.uni-saarland.de>:
> >> Could you also refer to r248616 and see whether the naming makes more
> >> sense in combination?
> > In r248616 you distinguish SCALAR, PHI and EXPLICIT, right?
> > Here "implicit" is gone but "explicit" stays (which could/should be MEMORY).
> 
> bool isExplicit() const { return Origin == EXPLICIT; }
> bool isImplicit() const { return !isExplicit(); }
> 
> "implicit" was never even mentioned in this commit (r248603).
And with
  s/isImplicit/!isMemory/
it won't be needed any more :)

> Don't you think it would be paradoxical to instantiate a class called
> MemoryAccess with something else than MEMORY?
My first comment two mails ago stated we should rename the class,...
Furthermore we already do that... only after code generation scalars and
phi's are actually demoted to memory, before that we just pretend :)

> Just to illustrate why the naming scheme is consistent:
I fully agree! Though, s/Explicit/Memory/ will not change that :)


This discussion is again going nowhere. While polly::MemoryAccess is
called polly::MemoryAccess we cannot move away from the "explicit accesses"
anyway. However, if that class is renamed at some point (hopefully soon)
there is no need to talk about "explicit accesses" anymore because we
can call them what they by their name, memory accesses.

Cheers,
  Johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150926/49da4c04/attachment.sig>