On 14 September 2010 19:56, Seth Hetu <[email protected]> wrote:
>>>> I'd definitely avoid this situation with gusto. Consider passing '3'
>>>> (just the number) as "by ref" into the parameter 'x' ---what happens
>>>> if the compiler inlines that variable, copying it to each place the
>>>> variable is used inside the function? That becomes problematic for,
>>>> e.g.,:
>>>> x = 10
>>>> ....which becomes:
>>>> 3 = 10
>>
>> That's not how function inlining works. And fbc is miles off doing any
>> optimisations as significant as function inlining anyway.
>
> I was under the impression that function inlining (e.g., inline
> expansion) included constant propagation as one of its steps.
Function inlining would be performed on an intermediate
representation; by that point it can probably be accomplished by
simply inserting the IR operations of the inlined function into the
caller with register renaming. So
void foo(int &bar) { bar = 10; }
...
foo(3)
probably becomes
<temp_arg0_reg> = 3
<temp_arg0_reg> = 10
Constant propagation is its own optimisation step; however compilers
can run optimisation steps multiple times and it's likely they'll
rerun something like constant propagation after doing inlining. I'm
looking for a certain GCC internals documentation that listed all the
optimisation passes in the order they are applied, but I can't find
it, nor anything that detailed on the GCC internals wiki.
While I'm on the subject of GCC internals: http://gcc.gnu.org/wiki/reload
And what might the OHRRPGCE equivalent be? ;)
>>>> That, at least, is the reason it's illegal in C++ ---not sure what
>>>> the FB compiler says if you try this.
>>
>> I don't think so. C++ can pass other types of temporary values by
>> reference, so I assume the reason it's illegal is that if you're
>> passing "3" by reference, it's probably an unintentional bug. Passing
>> by reference indicates that you want to pass a *variable* instead of a
>> value.
>>
>> And like I said, it works in FB.
>
> What you said makes more sense in this case. But then if passing by
> reference always works in FB, what happens if you pass '3' as a
> parameter by reference? Does it push a temporary variable to the stack
> and store '3' in there? Does it declare a temporary variable on the
> heap and pass its memory address to the function?
Mike answered this, but I'll add for amusement that though FB
generally does what you expect, it's still sometimes stupid. If you
have a temporary structure that contains a string and therefore needs
destructing and you write foo(make_temp_type), where foo takes its
argument BYVAL, FB will create an unnecessary 2nd copy of the
temporary object on the stack anyway. Not to mention that the copy
constructor is ridiculously inefficient, and unnecessarily calls the
constructor to blank out the memory before overwriting it. Probably a
hundred KB of game.exe and custom.exe are just inefficient
constructors, copy constructors, and destructors. I wouldn't be
surprised if our .exe files shrink to less than half size whenever we
get a C or C++ compilation backend.
> I'm just curious how FB manages this without corrupting memory. It
> seems like such a weird design choice.
>
> -->Seth
> _______________________________________________
> Ohrrpgce mailing list
> [email protected]
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
