llvm dev - Jul 2014 - [LLVMdev] The poor organization of TargetLowering (and related subclasses) is out of hand

(Sorry for CC'ing piles of people, but didn't want folks to miss this in
the mailing list churn.)

See the subject. The problem is in the target-independent code generator
and especially in the x86 backend.

I would like to fix it. This will be a mechanical change just organizing
code in a way that makes it easy and fast to find methods and related
static helpers. It will not change any actual functionality. But it will
pretty much completely break the utility of looking at only a single layer
of blame. Fortunately we have nice tools like 'git blame' that can step
incrementally back through time.

If anyone is radically opposed to me cleaning up TargetLowering.h,
TargetLoweringBase.cpp, and X86ISelLowering.{h,cpp}, shout. Otherwise, I
will clean this up with a vengence. I've CC'ed piles of folks who are
actively contributing and might be seriously impacted to make sure I don't
really make life horrible for folks.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140702/0b96c94a/attachment.html>

+1 Have at IMO :)

-eric

On Wed, Jul 2, 2014 at 6:00 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> (Sorry for CC'ing piles of people, but didn't want folks to miss
this in the
> mailing list churn.)
>
> See the subject. The problem is in the target-independent code generator
and
> especially in the x86 backend.
>
> I would like to fix it. This will be a mechanical change just organizing
> code in a way that makes it easy and fast to find methods and related
static
> helpers. It will not change any actual functionality. But it will pretty
> much completely break the utility of looking at only a single layer of
> blame. Fortunately we have nice tools like 'git blame' that can
step
> incrementally back through time.
>
> If anyone is radically opposed to me cleaning up TargetLowering.h,
> TargetLoweringBase.cpp, and X86ISelLowering.{h,cpp}, shout. Otherwise, I
> will clean this up with a vengence. I've CC'ed piles of folks who
are
> actively contributing and might be seriously impacted to make sure I
don't
> really make life horrible for folks.
>
> -Chandler
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

+1 and thanks :)

  Filipe

On Wednesday, July 2, 2014, Eric Christopher <echristo at gmail.com>
wrote:
> +1 Have at IMO :)
>
> -eric
>
> On Wed, Jul 2, 2014 at 6:00 PM, Chandler Carruth <chandlerc at gmail.com
> <javascript:;>> wrote:
> > (Sorry for CC'ing piles of people, but didn't want folks to
miss this in
> the
> > mailing list churn.)
> >
> > See the subject. The problem is in the target-independent code
generator
> and
> > especially in the x86 backend.
> >
> > I would like to fix it. This will be a mechanical change just
organizing
> > code in a way that makes it easy and fast to find methods and related
> static
> > helpers. It will not change any actual functionality. But it will
pretty
> > much completely break the utility of looking at only a single layer of
> > blame. Fortunately we have nice tools like 'git blame' that
can step
> > incrementally back through time.
> >
> > If anyone is radically opposed to me cleaning up TargetLowering.h,
> > TargetLoweringBase.cpp, and X86ISelLowering.{h,cpp}, shout. Otherwise,
I
> > will clean this up with a vengence. I've CC'ed piles of folks
who are
> > actively contributing and might be seriously impacted to make sure I
> don't
> > really make life horrible for folks.
> >
> > -Chandler
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu <javascript:;>        
http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>

-- 
  F
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140702/79c5ca48/attachment.html>

Please!  Thanks for checking.
> On Jul 2, 2014, at 6:00 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 
> (Sorry for CC'ing piles of people, but didn't want folks to miss
this in the mailing list churn.)
> 
> See the subject. The problem is in the target-independent code generator
and especially in the x86 backend.
> 
> I would like to fix it. This will be a mechanical change just organizing
code in a way that makes it easy and fast to find methods and related static
helpers. It will not change any actual functionality. But it will pretty much
completely break the utility of looking at only a single layer of blame.
Fortunately we have nice tools like 'git blame' that can step
incrementally back through time.
> 
> If anyone is radically opposed to me cleaning up TargetLowering.h,
TargetLoweringBase.cpp, and X86ISelLowering.{h,cpp}, shout. Otherwise, I will
clean this up with a vengence. I've CC'ed piles of folks who are
actively contributing and might be seriously impacted to make sure I don't
really make life horrible for folks.
> 
> -Chandler
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

No objections. Quite the contrary. 
> On Jul 2, 2014, at 6:00 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 
> (Sorry for CC'ing piles of people, but didn't want folks to miss
this in the mailing list churn.)
> 
> See the subject. The problem is in the target-independent code generator
and especially in the x86 backend.
> 
> I would like to fix it. This will be a mechanical change just organizing
code in a way that makes it easy and fast to find methods and related static
helpers. It will not change any actual functionality. But it will pretty much
completely break the utility of looking at only a single layer of blame.
Fortunately we have nice tools like 'git blame' that can step
incrementally back through time.
> 
> If anyone is radically opposed to me cleaning up TargetLowering.h,
TargetLoweringBase.cpp, and X86ISelLowering.{h,cpp}, shout. Otherwise, I will
clean this up with a vengence. I've CC'ed piles of folks who are
actively contributing and might be seriously impacted to make sure I don't
really make life horrible for folks.
> 
> -Chandler

How can X86ISelLowering.cpp be out of hand, it’s only 23k lines of code ;). 
Good luck!

On Jul 2, 2014, at 6:00 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> (Sorry for CC'ing piles of people, but didn't want folks to miss
this in the mailing list churn.)
> 
> See the subject. The problem is in the target-independent code generator
and especially in the x86 backend.
> 
> I would like to fix it. This will be a mechanical change just organizing
code in a way that makes it easy and fast to find methods and related static
helpers. It will not change any actual functionality. But it will pretty much
completely break the utility of looking at only a single layer of blame.
Fortunately we have nice tools like 'git blame' that can step
incrementally back through time.
> 
> If anyone is radically opposed to me cleaning up TargetLowering.h,
TargetLoweringBase.cpp, and X86ISelLowering.{h,cpp}, shout. Otherwise, I will
clean this up with a vengence. I've CC'ed piles of folks who are
actively contributing and might be seriously impacted to make sure I don't
really make life horrible for folks.
> 
> -Chandler

> On Jul 2, 2014, at 6:00 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 
> (Sorry for CC'ing piles of people, but didn't want folks to miss
this in the mailing list churn.)
> 
> See the subject. The problem is in the target-independent code generator
and especially in the x86 backend.
> 
> I would like to fix it. This will be a mechanical change just organizing
code in a way that makes it easy and fast to find methods and related static
helpers. It will not change any actual functionality. But it will pretty much
completely break the utility of looking at only a single layer of blame.
Fortunately we have nice tools like 'git blame' that can step
incrementally back through time.
> 
> If anyone is radically opposed to me cleaning up TargetLowering.h,
TargetLoweringBase.cpp, and X86ISelLowering.{h,cpp}, shout. Otherwise, I will
clean this up with a vengence. I've CC'ed piles of folks who are
actively contributing and might be seriously impacted to make sure I don't
really make life horrible for folks.
> 
> -Chandler
+1. Good luck. If I remember correctly there is a circular dependency problem in
TargetLowering.{h,cpp} and that’s why so much stuff goes into the .h file. It
would be nice to see this problem goes away. Also, breaking X86ISelLowering.cpp
into multiple files sounds like an excellent idea. Thanks for working on this
Chandler!