LLVM Expansions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

LLVM Expansions

Wilfred L. Guerin
It is very relevant that LLVM look into handeling HDL and other binary
and analogue operation modeling capbilities, as well as expand this
abstractly above in the other direction to include complex structure
optimization that is critical in realtime, dynamic and VM operations.

Without confirming the true characteristics of the lower structure
types and operating characteristics (especially physical
implementation) it is not possible to coherently optimize complex code
sequences, especially with wide varieties of influences on abstract
operation.

Obviously, all characteristics of physical system implmentation should
be included in the standard techniques.

More importantly, given most of that model data (result values) is
fairly finite and known variable data ranges for most target
implementations, one must propogate these analytics to higher models.

There is no difference between the physics simulation techniques used
to confirm the physical chips and the same modeling through operations
sequences all the way up to complex physical modeling.

Here, though, is an immediate need to be able to model and optimize
for entire computational systems regardless of scope.

GPU, fpga, solid asic, cpu and memory... various signaling techniques
between locally... interdependencies beyond local arrangements.

The need to handle "signals propogation" models, including the physics
of telecom and the hardware characteristics of intermediate devices,
mandates a coherent and comprehensive modeling technique through the
entire scope of influencing structures.

Specificly: you can NOT design optimal multi proc or diverse proc
implementations without knowing everything (composite model) about
everything involved.

Typically one designs systems based on the entire system.

Code optimization must accomodate this awareness as well as introduce
advanced modeling to more simple designs. (conventional code
modernization)

I will indicate as well that complex physical systems also effect
computational optimization. Heat at a data center or on fiber mutex
causes some deviance from ideal specs. It is hot on that wire. Your
computation will stall due to telecom latency that CAN ALWAYS BE
MODELED and accomodated. Sure, if the last packet from remote proc was
late, you can guess about the next, but if you are running at midday
summer and this happens daily, changing the scheduling order is
mandatory.

I will also indicate that the set of variable characteristics used in
process modeling is identical numerically to that used in higher level
physics simulation. Everything from atomic physics (fpga) through
automobile heat and mechanical force transfer (turbulance and
environmental conditions at repeater) (wire) are of the exact same
processing technique and data set (superset with only the processing
technique differing).

Thus:

Both in order to accurately simulate and optimize modern computational
models, and due to the fundamental similarities in computational
process, LLVM should expand to handle ALL lower dependencies (hdl/etc)
(which are an obvious need anyways) as well as applying the techniques
of process modeling to all other similar mechanisms.

You will note that 3rd party scientific processes could easily be
optimized intrinsicly when the scope of their numerical model is
known, which depends on such things as materials physics specs and fea
modeling of ... the exact same systems that are thus selected to run
the model on.

There are few modern abstract modeling languages and systems, and most
are restricted use and highly isolated.

Code depends on hardware, operations depend on physical reality.

Obviously there is a need to fabricate the most comprehensive system
model now (all data options handled), allow optimal techniques to be
introduced later, and generate a finite set of modeling techniques
that handle most of the required situations.

I look forward to your response and discussions of this topic.

-Wilfred L. Guerin
[hidden email]
aim/msn/yp/gt/sk/etc "WilfredGuerin" icq 105758521



.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM Expansions

nkavv
> From: "Wilfred L. Guerin" <[hidden email]>
> Subject: [LLVMdev] LLVM Expansions
>
> It is very relevant that LLVM look into handeling HDL and other binary
> and analogue operation modeling capbilities, as well as expand this

what is binary? you mean digital right?

> Without confirming the true characteristics of the lower structure
> types and operating characteristics (especially physical
> implementation) it is not possible to coherently optimize complex code
> sequences, especially with wide varieties of influences on abstract
> operation.

What a mess! ARE YOU MAN OR BOT???
I may be tired (late night, coffee cup toll rises!) BUT MAN YOU ARE
INCOMPREHENSIBLE.

Dear LLVMers are you sure this guy exists?

> Obviously, all characteristics of physical system implmentation should
> be included in the standard techniques.
...driniking more coffee...

> More importantly, given most of that model data (result values) is
> fairly finite and known variable data ranges for most target
> implementations, one must propogate these analytics to higher models.

"data ranges"? In the essence of what can be extracted from "bitwidth analysis".
Oh, man, your text is certainly machine-generated. Have you translated this from
s'thing to English, and acquired the nice nop de plume?

These are my thoughts to your highly entropic stuff. In the slight case you are
man, please refine on your thoughts.

Cheers, bot boy!
Nikolaos Kavvadias

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM Expansions

Wilfred L. Guerin
perhaps one should ask why a compiler has not compiled itself to
binary and requires a 3rd party compiler to exist.

Someone please send me lli that works on a pxa270 (which has never
been tested?) and make sure it runs in PocketPC(win) so I dont have to
wait another 20 hours to compile a damned compiler.



On 7/24/07, [hidden email] <[hidden email]> wrote:

> > From: "Wilfred L. Guerin" <[hidden email]>
> > Subject: [LLVMdev] LLVM Expansions
> >
> > It is very relevant that LLVM look into handeling HDL and other binary
> > and analogue operation modeling capbilities, as well as expand this
>
> what is binary? you mean digital right?
>
> > Without confirming the true characteristics of the lower structure
> > types and operating characteristics (especially physical
> > implementation) it is not possible to coherently optimize complex code
> > sequences, especially with wide varieties of influences on abstract
> > operation.
>
> What a mess! ARE YOU MAN OR BOT???
> I may be tired (late night, coffee cup toll rises!) BUT MAN YOU ARE
> INCOMPREHENSIBLE.
>
> Dear LLVMers are you sure this guy exists?
>
> > Obviously, all characteristics of physical system implmentation should
> > be included in the standard techniques.
> ...driniking more coffee...
>
> > More importantly, given most of that model data (result values) is
> > fairly finite and known variable data ranges for most target
> > implementations, one must propogate these analytics to higher models.
>
> "data ranges"? In the essence of what can be extracted from "bitwidth
> analysis".
> Oh, man, your text is certainly machine-generated. Have you translated this
> from
> s'thing to English, and acquired the nice nop de plume?
>
> These are my thoughts to your highly entropic stuff. In the slight case you
> are
> man, please refine on your thoughts.
>
> Cheers, bot boy!
> Nikolaos Kavvadias
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM expansions

nkavv
In reply to this post by Wilfred L. Guerin
> perhaps one should ask why a compiler has not compiled itself to
> binary and requires a 3rd party compiler to exist.

I think this is the case unless the compiler you are talking about can
bootstrap.


> Someone please send me lli that works on a pxa270 (which has never
> been tested?) and make sure it runs in PocketPC(win) so I dont have to
> wait another 20 hours to compile a damned compiler.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM Expansions

Bill Wendling
In reply to this post by Wilfred L. Guerin
On Jul 24, 2007, at 8:34 PM, Wilfred L. Guerin wrote:

> perhaps one should ask why a compiler has not compiled itself to
> binary and requires a 3rd party compiler to exist.

LLVM has compiled itself to "binary".

> Someone please send me lli that works on a pxa270

No.

> (which has never been tested?) and make sure it runs in PocketPC
> (win) so I dont have to
> wait another 20 hours to compile a damned compiler.

You've chosen a poor platform to compile a compiler on.

-bw
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM Expansions

Ralph Corderoy
In reply to this post by nkavv

Hi Nikolaos,

> What a mess! ARE YOU MAN OR BOT???
> I may be tired (late night, coffee cup toll rises!) BUT MAN YOU ARE
> INCOMPREHENSIBLE.
> ...
> Cheers, bot boy!

If you're tired and have to resort to shouting and insults then don't
post.  Just delete the email or wait until you're less tired and
consider again.

LLVMdev is a friendly place.  Let's keep it that way.  If a newcomer
crops up with questions and comments you don't understand then explain
so nicely without using ad hominem attacks, or let someone else reply.

Cheers,


Ralph.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: LLVM Expansions

Chris Lattner
On Wed, 25 Jul 2007, Ralph Corderoy wrote:
> LLVMdev is a friendly place.  Let's keep it that way.  If a newcomer
> crops up with questions and comments you don't understand then explain
> so nicely without using ad hominem attacks, or let someone else reply.

Totally agreed!

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev